AWS effectue des ajustements sur un Large Language Model (LLM) pour classer les discours toxiques pour une grande société de jeux | Services Web Amazon

L'industrie du jeu vidéo a une base d'utilisateurs estimée à plus de 3 milliards dans le monde¹. Il se compose d'énormes quantités de joueurs interagissant virtuellement les uns avec les autres chaque jour. Malheureusement, comme dans le monde réel, tous les joueurs ne communiquent pas de manière appropriée et respectueuse. Dans le but de créer et de maintenir un environnement de jeu socialement responsable, AWS Professional Services a été invité à créer un mécanisme qui détecte le langage inapproprié (discours toxique) dans les interactions des joueurs de jeux en ligne. Le résultat commercial global était d'améliorer les opérations de l'organisation en automatisant un processus manuel existant et d'améliorer l'expérience utilisateur en augmentant la vitesse et la qualité de la détection des interactions inappropriées entre les joueurs, favorisant ainsi un environnement de jeu plus propre et plus sain.

La demande du client était de créer un détecteur de langue anglaise qui classe les extraits de voix et de texte dans leurs propres catégories de langue toxique définies sur mesure. Ils voulaient d'abord déterminer si l'extrait de langage donné est toxique, puis classer l'extrait dans une catégorie spécifique de toxicité définie par le client, comme le blasphème ou le langage abusif.

AWS ProServe a résolu ce cas d'utilisation grâce à un effort conjoint entre le Generative AI Innovation Center (GAIIC) et l'équipe ProServe ML Delivery Team (MLDT). L'AWS GAIIC est un groupe au sein d'AWS ProServe qui associe des clients à des experts pour développer des solutions d'IA génératives pour un large éventail de cas d'utilisation commerciale à l'aide de versions de preuve de concept (PoC). AWS ProServe MLDT prend ensuite le PoC en production en mettant à l'échelle, en renforçant et en intégrant la solution pour le client.

Ce cas d'utilisation client sera présenté dans deux articles distincts. Cet article (Partie 1) sert de plongée profonde dans la méthodologie scientifique. Il expliquera le processus de réflexion et d'expérimentation derrière la solution, y compris le processus de formation et de développement du modèle. La partie 2 plongera dans la solution produite, expliquant les décisions de conception, le flux de données et l'illustration de l'architecture de formation et de déploiement du modèle.

Ce billet couvre les sujets suivants :

• Les défis qu'AWS ProServe a dû résoudre pour ce cas d'utilisation
• Contexte historique des grands modèles de langage (LLM) et pourquoi cette technologie est parfaitement adaptée à ce cas d'utilisation
• PoC d'AWS GAIIC et solution d'AWS ProServe MLDT du point de vue de la science des données et de l'apprentissage automatique (ML)

Défi des données

Le principal défi auquel AWS ProServe était confronté lors de la formation d'un classificateur de langage toxique consistait à obtenir suffisamment de données étiquetées du client pour former un modèle précis à partir de zéro. AWS a reçu environ 100 échantillons de données étiquetées du client, ce qui est bien moins que les 1,000 XNUMX échantillons recommandés pour affiner un LLM dans la communauté des sciences des données.

En tant que défi inhérent supplémentaire, les classificateurs de traitement du langage naturel (TLN) sont historiquement connus pour être très coûteux à former et nécessitent un large ensemble de vocabulaire, connu sous le nom de corpus, pour produire des prédictions précises. Une solution NLP rigoureuse et efficace, si elle fournissait des quantités suffisantes de données étiquetées, consisterait à former un modèle de langage personnalisé à l'aide des données étiquetées du client. Le modèle serait formé uniquement avec le vocabulaire de jeu des joueurs, ce qui le rendrait adapté au langage observé dans les jeux. Le client avait à la fois des contraintes de coût et de temps qui rendaient cette solution non viable. AWS ProServe a été contraint de trouver une solution pour former un classificateur de toxicité linguistique précis avec un ensemble de données étiquetées relativement petit. La solution réside dans ce qu'on appelle transférer l'apprentissage.

L'idée derrière l'apprentissage par transfert est d'utiliser les connaissances d'un modèle pré-formé et de l'appliquer à un problème différent mais relativement similaire. Par exemple, si un classificateur d'images a été formé pour prédire si une image contient un chat, vous pouvez utiliser les connaissances que le modèle a acquises au cours de sa formation pour reconnaître d'autres animaux comme les tigres. Pour ce cas d'utilisation de langage, AWS ProServe devait trouver un classificateur de langage préalablement formé pour détecter le langage toxique et l'affiner à l'aide des données étiquetées du client.

La solution était de trouver et d'affiner un LLM pour classer le langage toxique. Les LLM sont des réseaux de neurones formés à l'aide d'un nombre considérable de paramètres, généralement de l'ordre de milliards, à l'aide de données non étiquetées. Avant d'aborder la solution AWS, la section suivante donne un aperçu de l'historique des LLM et de leurs cas d'utilisation historiques.

Exploiter la puissance des LLM

Les LLM sont récemment devenus le point focal pour les entreprises à la recherche de nouvelles applications de ML, depuis que ChatGPT a conquis l'esprit du public en étant l'application grand public à la croissance la plus rapide de l'histoire.², atteignant 100 millions d'utilisateurs actifs d'ici janvier 2023, 2 mois seulement après sa sortie. Cependant, les LLM ne sont pas une nouvelle technologie dans l'espace ML. Ils ont été largement utilisés pour effectuer des tâches de PNL telles que l'analyse de sentiments, la synthèse de corpus, l'extraction de mots-clés, la traduction de discours et la classification de texte.

En raison de la nature séquentielle du texte, les réseaux de neurones récurrents (RNN) étaient à la pointe de la technologie pour la modélisation NLP. Plus précisément, le encodeur-décodeur L'architecture de réseau a été formulée parce qu'elle a créé une structure RNN capable de prendre une entrée de longueur arbitraire et de générer une sortie de longueur arbitraire. C'était idéal pour les tâches NLP comme la traduction où une phrase de sortie d'une langue pouvait être prédite à partir d'une phrase d'entrée d'une autre langue, généralement avec des nombres de mots différents entre l'entrée et la sortie. L'architecture du transformateur³ (Vaswani, 2017) était une amélioration révolutionnaire de l'encodeur-décodeur ; il a introduit le concept de attention à soi, ce qui a permis au modèle de concentrer son attention sur différents mots dans les phrases d'entrée et de sortie. Dans un codeur-décodeur typique, chaque mot est interprété par le modèle de manière identique. Comme le modèle traite séquentiellement chaque mot d'une phrase d'entrée, les informations sémantiques du début peuvent être perdues à la fin de la phrase. Le mécanisme d'auto-attention a changé cela en ajoutant une couche d'attention à la fois au bloc encodeur et au bloc décodeur, de sorte que le modèle puisse attribuer des pondérations différentes à certains mots de la phrase d'entrée lors de la génération d'un certain mot dans la phrase de sortie. Ainsi est née la base du modèle de transformateur.

L'architecture du transformateur a été à la base de deux des LLM les plus connus et les plus populaires utilisés aujourd'hui, les représentations d'encodeur bidirectionnel des transformateurs (BERT)⁴ (Radford, 2018) et le transformateur pré-entraîné génératif (GPT)⁵ (Devlin 2018). Les versions ultérieures du modèle GPT, à savoir GPT3 et GPT4, sont le moteur qui alimente l'application ChatGPT. Le dernier élément de la recette qui rend les LLM si puissants est la capacité de distiller des informations à partir de vastes corpus de texte sans étiquetage ni prétraitement approfondis via un processus appelé ULMFiT. Cette méthode a une phase de pré-formation où le texte général peut être rassemblé et le modèle est formé sur la tâche de prédire le mot suivant en fonction des mots précédents ; l'avantage ici est que tout texte d'entrée utilisé pour la formation est intrinsèquement pré-étiqueté en fonction de l'ordre du texte. Les LLM sont vraiment capables d'apprendre à partir de données à l'échelle d'Internet. Par exemple, le modèle BERT original a été pré-formé sur le BookCorpus et sur l'ensemble des ensembles de données textuelles de Wikipédia en anglais.

Ce nouveau paradigme de modélisation a donné naissance à deux nouveaux concepts : les modèles de fondation (FM) et l'IA générative. Contrairement à la formation d'un modèle à partir de zéro avec des données spécifiques à une tâche, ce qui est le cas habituel pour l'apprentissage supervisé classique, les LLM sont pré-formés pour extraire des connaissances générales à partir d'un ensemble de données de texte large avant d'être adaptés à des tâches ou à des domaines spécifiques avec un beaucoup plus petit. ensemble de données (généralement de l'ordre de centaines d'échantillons). Le nouveau flux de travail ML démarre désormais avec un modèle pré-formé appelé modèle de base. Il est important de construire sur de bonnes bases, et il existe un nombre croissant d'options, telles que le nouveau Amazon Titan FM, qui sera publié par AWS dans le cadre de Socle amazonien. Ces nouveaux modèles sont également considérés comme génératifs car leurs sorties sont interprétables par l'homme et dans le même type de données que les données d'entrée. Alors que les anciens modèles ML étaient descriptifs, tels que la classification des images de chats par rapport aux chiens, les LLM sont génératifs car leur sortie est le prochain ensemble de mots basé sur les mots d'entrée. Cela leur permet d'alimenter des applications interactives telles que ChatGPT qui peuvent être expressives dans le contenu qu'elles génèrent.

Hugging Face s'est associé à AWS pour démocratiser les FM et les rendre faciles d'accès et de construction. Hugging Face a créé un API des transformateurs qui unifie plus de 50 architectures de transformateurs différentes sur différents frameworks ML, y compris l'accès à des poids de modèle pré-formés dans leur Model Hub, qui est passé à plus de 200,000 XNUMX modèles au moment de la rédaction de cet article. Dans les sections suivantes, nous explorons la preuve de concept, la solution et les FM qui ont été testés et choisis comme base pour résoudre ce cas d'utilisation de la classification de la parole toxique pour le client.

Preuve de concept AWS GAIIC

AWS GAIIC a choisi d'expérimenter les modèles de base LLM avec l'architecture BERT pour affiner un classificateur de langage toxique. Au total, trois modèles du hub de modèles de Hugging Face ont été testés :

Les trois architectures modèles sont basées sur le BERTweet architecture. BERTweet est formé sur la base du ROBERTa procédure de pré-formation. La procédure de pré-formation RoBERTa est le résultat d'une étude de réplication de la pré-formation BERT qui a évalué les effets du réglage des hyperparamètres et de la taille de l'ensemble de formation pour améliorer la recette de formation des modèles BERT⁶ (Liu 2019). L'expérience visait à trouver une méthode de pré-formation qui améliorait les résultats de performance du BERT sans modifier l'architecture sous-jacente. La conclusion de l'étude a révélé que les modifications de pré-formation suivantes ont considérablement amélioré les performances du BERT :

• Entraîner le modèle avec des lots plus importants sur plus de données
• Suppression de l'objectif de prédiction de la phrase suivante
• Entraînement sur des séquences plus longues
• Modification dynamique du motif de masquage appliqué aux données d'apprentissage

Le modèle de base de bertweet utilise la procédure de pré-formation précédente de l'étude RoBERTa pour pré-former l'architecture originale du BERT en utilisant 850 millions de tweets en anglais. Il s'agit du premier modèle de langage public à grande échelle pré-formé pour les tweets en anglais.

On pensait que les FM pré-formés utilisant des tweets correspondaient au cas d'utilisation pour deux raisons théoriques principales :

• La longueur d'un tweet est très similaire à la longueur d'une phrase inappropriée ou toxique trouvée dans les chats de jeux en ligne
• Les tweets proviennent d'une population avec une grande variété d'utilisateurs différents, similaire à celle de la population trouvée dans les plateformes de jeux

AWS a décidé d'abord d'affiner BERTweet avec les données étiquetées du client pour obtenir une base de référence. Ensuite, nous avons choisi d'affiner deux autres FM en bertweet-base-offensive et bertweet-base-haine qui ont été pré-formés spécifiquement sur des tweets toxiques plus pertinents pour atteindre une précision potentiellement plus élevée. Le modèle bertweet-base-offensive utilise la base BertTweet FM et est en outre pré-formé sur 14,100 XNUMX tweets annotés qui ont été jugés offensants⁷ (Zampieri 2019). Le modèle bertweet-base-hate utilise également la base BertTweet FM mais est en outre pré-formé sur 19,600 XNUMX tweets considérés comme des discours de haine⁸ (Basile 2019).

Pour améliorer encore les performances du modèle PoC, AWS GAIIC a pris deux décisions de conception :

• Création d'un flux de prédiction en deux étapes où le premier modèle agit comme un classificateur binaire qui classe si un morceau de texte est toxique ou non toxique. Le deuxième modèle est un modèle à grain fin qui classe le texte en fonction des types de toxiques définis par le client. Ce n'est que si le premier modèle prédit que le texte est toxique qu'il est transmis au second modèle.
• Augmentation des données d'entraînement et ajout d'un sous-ensemble d'un ensemble de données de texte toxique étiqueté par un tiers à partir d'un concours public Kaggle (Toxicité du puzzle) aux 100 échantillons originaux reçus du client. Ils ont mappé les étiquettes Jigsaw sur les étiquettes de toxicité associées définies par le client et ont divisé 80 % en tant que données de formation et 20 % en tant que données de test pour valider le modèle.

AWS GAIIC utilisé Amazon Sage Maker ordinateurs portables pour exécuter leurs expériences de réglage fin et ont constaté que le modèle bertweet-base-offensive obtenait les meilleurs scores sur l'ensemble de validation. Le tableau suivant résume les scores des métriques observés.

À partir de ce moment, GAIIC a transmis le PoC à l'équipe de livraison AWS ProServe ML pour produire le PoC.

Solution AWS ProServe ML Delivery Team

Pour produire l'architecture du modèle, le client a demandé à l'équipe de livraison AWS ProServe ML (MLDT) de créer une solution évolutive et facile à entretenir. Il y avait quelques défis de maintenance d'une approche de modèle en deux étapes :

• Les modèles nécessiteraient le double de la quantité de surveillance du modèle, ce qui rend le calendrier de recyclage incohérent. Il peut arriver qu'un modèle doive être recyclé plus souvent qu'un autre.
• Augmentation des coûts d'exploitation de deux modèles au lieu d'un seul.
• La vitesse d'inférence ralentit car l'inférence passe par deux modèles.

Pour relever ces défis, AWS ProServe MLDT a dû trouver comment transformer l'architecture de modèle en deux étapes en une architecture de modèle unique tout en étant capable de maintenir la précision de l'architecture en deux étapes.

La solution consistait d'abord à demander au client plus de données d'entraînement, puis à affiner le modèle bertweet-base-offensive sur toutes les étiquettes, y compris les échantillons non toxiques, en un seul modèle. L'idée était que le réglage fin d'un modèle avec plus de données donnerait des résultats similaires au réglage fin d'une architecture de modèle en deux étapes sur moins de données. Pour affiner l'architecture du modèle en deux étapes, AWS ProServe MLDT a mis à jour la tête de classification multi-étiquettes du modèle pré-formé pour inclure un nœud supplémentaire pour représenter la classe non toxique.

Voici un exemple de code montrant comment affiner un modèle pré-formé à partir du hub de modèles Hugging Face à l'aide de leur plate-forme de transformateurs et modifier la tête de classification multi-étiquettes du modèle pour prédire le nombre de classes souhaité. AWS ProServe MLDT a utilisé ce plan comme base pour le réglage fin. Il suppose que vous avez vos données de train et vos données de validation prêtes et dans le bon format d'entrée.

Tout d'abord, les modules Python sont importés ainsi que le modèle pré-formé souhaité à partir du hub de modèles 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)

Le modèle pré-formé est ensuite chargé et préparé pour un réglage fin. C'est l'étape où le nombre de catégories toxiques et tous les paramètres du modèle sont définis :

# 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], )

Le réglage fin du modèle commence par la saisie de chemins vers les ensembles de données d'entraînement et de validation :

# 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()

AWS ProServe MLDT a reçu environ 5,000 3,000 échantillons de données étiquetés supplémentaires, 2,000 5,000 étant non toxiques et 80 20 étant toxiques, et a affiné les trois modèles de base de bertweet, combinant toutes les étiquettes en un seul modèle. Ils ont utilisé ces données en plus des XNUMX XNUMX échantillons du PoC pour affiner de nouveaux modèles à une étape en utilisant la même méthode d'ensemble de train à XNUMX % et d'ensemble de test à XNUMX %. Le tableau suivant montre que les scores de performance étaient comparables à ceux du modèle en deux étapes.

L'approche du modèle en une étape a permis d'améliorer les coûts et la maintenance tout en ne diminuant la précision que de 3 %. Après avoir pesé les compromis, le client a opté pour AWS ProServe MLDT pour produire le modèle en une étape.

En affinant un modèle avec davantage de données étiquetées, AWS ProServe MLDT a pu fournir une solution qui répondait au seuil de précision du modèle du client, ainsi que répondre à sa demande de facilité de maintenance, tout en réduisant les coûts et en augmentant la robustesse.

Conclusion

Un grand client de jeux cherchait un moyen de détecter le langage toxique dans ses canaux de communication afin de promouvoir un environnement de jeu socialement responsable. AWS GAIIC a créé un PoC d'un détecteur de langage toxique en affinant un LLM pour détecter le langage toxique. AWS ProServe MLDT a ensuite mis à jour le flux de formation du modèle d'une approche en deux étapes à une approche en une étape et a produit le LLM pour que le client l'utilise à grande échelle.

Dans cet article, AWS démontre l'efficacité et l'aspect pratique du réglage fin d'un LLM pour résoudre ce cas d'utilisation client, partage le contexte sur l'historique des modèles de base et des LLM, et présente le flux de travail entre AWS Generative AI Innovation Center et AWS ProServe ML Équipe de livraison. Dans le prochain article de cette série, nous approfondirons la façon dont AWS ProServe MLDT a produit le modèle en une étape résultant à l'aide de SageMaker.

Si vous souhaitez travailler avec AWS pour créer une solution d'IA générative, veuillez contacter le GAIIC. Ils évalueront votre cas d'utilisation, élaboreront une preuve de concept basée sur l'IA générative et auront des options pour étendre la collaboration avec AWS afin de mettre en œuvre le PoC résultant en production.

Bibliographie

1. Démographie des joueurs : faits et statistiques sur le passe-temps le plus populaire au monde
2. ChatGPT établit un record pour la base d'utilisateurs à la croissance la plus rapide - note d'analyste
3. Vaswani et al., "L'attention est tout ce dont vous avez besoin"
4. Radford et al., "Améliorer la compréhension du langage par la pré-formation générative"
5. Devlin et al., "BERT : Pré-formation des transformateurs bidirectionnels profonds pour la compréhension du langage"
6. Yinhan Liu et al., "RoBERTa : une approche de préformation BERT optimisée de manière robuste"
7. Marcos Zampieri et al., "SemEval-2019 Tâche 6 : Identifier et catégoriser le langage offensant dans les médias sociaux (OffensEval)"
8. Valerio Basile et al., « SemEval-2019 Tâche 5 : Détection multilingue des discours de haine contre les immigrés et les femmes sur Twitter »

À propos des auteurs

James Poquiz est un Data Scientist chez AWS Professional Services basé dans le comté d'Orange, en Californie. Il est titulaire d'un BS en informatique de l'Université de Californie à Irvine et a plusieurs années d'expérience dans le domaine des données, ayant joué de nombreux rôles différents. Aujourd'hui, il travaille à la mise en œuvre et au déploiement de solutions de ML évolutives pour obtenir des résultats commerciaux pour les clients AWS.

Homme Han est un responsable principal de la science des données et de l'apprentissage automatique chez AWS Professional Services basé à San Diego, en Californie. Il est titulaire d'un doctorat en ingénierie de l'Université Northwestern et possède plusieurs années d'expérience en tant que consultant en gestion conseillant des clients dans les domaines de la fabrication, des services financiers et de l'énergie. Aujourd'hui, il travaille avec passion avec des clients clés de divers secteurs verticaux pour développer et mettre en œuvre des solutions ML et GenAI sur AWS.

Safa Tinaztepe est un data scientist full-stack avec AWS Professional Services. Il est titulaire d'un BS en informatique de l'Université Emory et s'intéresse aux MLOps, aux systèmes distribués et au Web3.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Automobile / VE, Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• Décalages de bloc. Modernisation de la propriété des compensations environnementales. Accéder ici.
• La source: 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/