L'industria dei videogiochi ha una base di utenti stimata di oltre 3 miliardi in tutto il mondo¹. Consiste in enormi quantità di giocatori che interagiscono virtualmente tra loro ogni singolo giorno. Sfortunatamente, come nel mondo reale, non tutti i giocatori comunicano in modo appropriato e rispettoso. Nel tentativo di creare e mantenere un ambiente di gioco socialmente responsabile, ai servizi professionali AWS è stato chiesto di creare un meccanismo che rilevi il linguaggio inappropriato (discorso tossico) all'interno delle interazioni dei giocatori di gioco online. Il risultato aziendale complessivo è stato quello di migliorare le operazioni dell'organizzazione automatizzando un processo manuale esistente e migliorare l'esperienza utente aumentando la velocità e la qualità nel rilevare interazioni inappropriate tra i giocatori, promuovendo in definitiva un ambiente di gioco più pulito e sano.

La richiesta del cliente era di creare un rilevatore di lingua inglese che classifichi gli estratti vocali e di testo nelle proprie categorie linguistiche tossiche personalizzate. Volevano innanzitutto determinare se l'estratto linguistico dato è tossico, quindi classificare l'estratto in una specifica categoria di tossicità definita dal cliente come volgarità o linguaggio offensivo.

AWS ProServe ha risolto questo caso d'uso attraverso uno sforzo congiunto tra il Generative AI Innovation Center (GAIIC) e il ProServe ML Delivery Team (MLDT). AWS GAIIC è un gruppo all'interno di AWS ProServe che mette in contatto clienti ed esperti per sviluppare soluzioni di intelligenza artificiale generativa per un'ampia gamma di casi d'uso aziendali utilizzando build di proof of concept (PoC). AWS ProServe MLDT porta quindi il PoC attraverso la produzione ridimensionando, rafforzando e integrando la soluzione per il cliente.

Questo caso d'uso del cliente verrà presentato in due post separati. Questo post (Parte 1) funge da immersione profonda nella metodologia scientifica. Spiegherà il processo di pensiero e la sperimentazione alla base della soluzione, compreso il processo di formazione e sviluppo del modello. La parte 2 approfondirà la soluzione prodotta, spiegando le decisioni di progettazione, il flusso di dati e l'illustrazione dell'architettura di addestramento e distribuzione del modello.

Questo post tratta i seguenti argomenti:

• Le sfide che AWS ProServe ha dovuto risolvere per questo caso d'uso
• Contesto storico sui modelli di linguaggio di grandi dimensioni (LLM) e perché questa tecnologia è perfetta per questo caso d'uso
• Il PoC di AWS GAIIC e la soluzione MLDT di AWS ProServe da una prospettiva di data science e machine learning (ML)

Sfida sui dati

La sfida principale affrontata da AWS ProServe durante l'addestramento di un classificatore linguistico tossico è stata l'ottenimento dal cliente di dati etichettati sufficienti per addestrare un modello accurato da zero. AWS ha ricevuto dal cliente circa 100 campioni di dati etichettati, che è molto meno dei 1,000 campioni consigliati per la messa a punto di un LLM nella comunità di data science.

Come ulteriore sfida intrinseca, i classificatori di elaborazione del linguaggio naturale (PNL) sono storicamente noti per essere molto costosi da addestrare e richiedono un ampio set di vocaboli, noto come corpo, per produrre previsioni accurate. Una soluzione PNL rigorosa ed efficace, se vengono fornite quantità sufficienti di dati etichettati, consisterebbe nell'addestrare un modello linguistico personalizzato utilizzando i dati etichettati del cliente. Il modello verrebbe addestrato esclusivamente con il vocabolario di gioco dei giocatori, adattandolo alla lingua osservata nei giochi. Il cliente aveva vincoli sia di costo che di tempo che rendevano questa soluzione impraticabile. AWS ProServe è stato costretto a trovare una soluzione per addestrare un accurato classificatore di tossicità linguistica con un set di dati etichettato relativamente piccolo. La soluzione risiedeva in ciò che è noto come trasferire l'apprendimento.

L'idea alla base del transfer learning è quella di utilizzare la conoscenza di un modello pre-addestrato e applicarla a un problema diverso ma relativamente simile. Ad esempio, se un classificatore di immagini è stato addestrato per prevedere se un'immagine contiene un gatto, è possibile utilizzare la conoscenza acquisita dal modello durante l'addestramento per riconoscere altri animali come le tigri. Per questo caso d'uso linguistico, AWS ProServe aveva bisogno di trovare un classificatore linguistico addestrato in precedenza per rilevare il linguaggio tossico e perfezionarlo utilizzando i dati etichettati del cliente.

La soluzione era trovare e mettere a punto un LLM per classificare il linguaggio tossico. Gli LLM sono reti neurali che sono state addestrate utilizzando un numero enorme di parametri, in genere nell'ordine di miliardi, utilizzando dati non etichettati. Prima di entrare nella soluzione AWS, la sezione seguente fornisce una panoramica della cronologia degli LLM e dei relativi casi d'uso storici.

Sfruttando la potenza degli LLM

Gli LLM sono recentemente diventati il ​​punto focale per le aziende alla ricerca di nuove applicazioni di ML, sin da quando ChatGPT ha catturato l'opinione pubblica diventando l'applicazione consumer in più rapida crescita nella storia², raggiungendo 100 milioni di utenti attivi entro gennaio 2023, appena 2 mesi dopo il suo rilascio. Tuttavia, gli LLM non sono una nuova tecnologia nello spazio ML. Sono stati ampiamente utilizzati per eseguire attività di PNL come l'analisi del sentimento, il riepilogo di corpus, l'estrazione di parole chiave, la traduzione di discorsi e la classificazione del testo.

A causa della natura sequenziale del testo, le reti neurali ricorrenti (RNN) erano lo stato dell'arte per la modellazione della PNL. Nello specifico, il codificatore-decodificatore l'architettura di rete è stata formulata perché ha creato una struttura RNN in grado di accettare un input di lunghezza arbitraria e generare un output di lunghezza arbitraria. Questo era l'ideale per attività di PNL come la traduzione in cui una frase di output di una lingua poteva essere prevista da una frase di input di un'altra lingua, in genere con un numero di parole diverso tra l'input e l'output. L'architettura del trasformatore³ (Vaswani, 2017) è stato un miglioramento rivoluzionario del codificatore-decodificatore; ha introdotto il concetto di auto-attenzione, che ha consentito al modello di focalizzare la propria attenzione su parole diverse nelle frasi di input e output. In un tipico codificatore-decodificatore, ogni parola viene interpretata dal modello in modo identico. Poiché il modello elabora in sequenza ogni parola in una frase di input, le informazioni semantiche all'inizio potrebbero andare perse entro la fine della frase. Il meccanismo di auto-attenzione ha cambiato questa situazione aggiungendo un livello di attenzione sia al codificatore che al blocco decodificatore, in modo che il modello potesse attribuire ponderazioni diverse a determinate parole dalla frase di input durante la generazione di una determinata parola nella frase di output. Nacque così la base del modello del trasformatore.

L'architettura del trasformatore è stata la base per due dei più noti e popolari LLM in uso oggi, i Bidirectional Encoder Representations from Transformers (BERT)⁴ (Radford, 2018) e il Generative Pretrained Transformer (GPT)⁵ (Devlin 2018). Le versioni successive del modello GPT, ovvero GPT3 e GPT4, sono il motore che alimenta l'applicazione ChatGPT. L'ultimo pezzo della ricetta che rende gli LLM così potenti è la capacità di distillare informazioni da vasti corpus di testi senza etichettatura o pre-elaborazione estesa tramite un processo chiamato ULMFiT. Questo metodo ha una fase di pre-addestramento in cui è possibile raccogliere il testo generale e il modello viene addestrato sul compito di prevedere la parola successiva in base alle parole precedenti; il vantaggio qui è che qualsiasi testo di input utilizzato per l'addestramento viene intrinsecamente preetichettato in base all'ordine del testo. Gli LLM sono veramente in grado di imparare dai dati su scala Internet. Ad esempio, il modello BERT originale è stato preaddestrato sul BookCorpus e su interi set di dati di testo di Wikipedia in inglese.

Questo nuovo paradigma di modellazione ha dato origine a due nuovi concetti: i modelli di base (FM) e l'IA generativa. A differenza dell'addestramento di un modello da zero con dati specifici dell'attività, che è il solito caso per l'apprendimento supervisionato classico, gli LLM sono pre-addestrati per estrarre conoscenze generali da un ampio set di dati di testo prima di essere adattati a compiti o domini specifici con un molto più piccolo set di dati (tipicamente dell'ordine di centinaia di campioni). Il nuovo flusso di lavoro ML ora inizia con un modello preaddestrato denominato modello di base. È importante costruire sulle basi giuste e ci sono un numero crescente di opzioni, come il nuovo Amazon Titan FM, che sarà rilasciato da AWS come parte di Roccia Amazzonica. Questi nuovi modelli sono anche considerati generativi perché i loro output sono interpretabili dall'uomo e nello stesso tipo di dati dei dati di input. Mentre i precedenti modelli ML erano descrittivi, come la classificazione di immagini di gatti rispetto a cani, gli LLM sono generativi perché il loro output è il successivo insieme di parole basato sulle parole di input. Ciò consente loro di alimentare applicazioni interattive come ChatGPT che possono essere espressive nel contenuto che generano.

Hugging Face ha stretto una partnership con AWS per democratizzare i FM e renderli di facile accesso e compilazione. Hugging Face ha creato un API dei trasformatori che unifica più di 50 diverse architetture di trasformatori su diversi framework ML, incluso l'accesso ai pesi dei modelli pre-addestrati nelle loro Hub modello, che è cresciuto fino a oltre 200,000 modelli al momento della stesura di questo post. Nelle sezioni successive, esploreremo il proof of concept, la soluzione e gli FM che sono stati testati e scelti come base per risolvere questo caso d'uso tossico della classificazione vocale per il cliente.

Prova di concetto AWS GAIIC

AWS GAIIC ha scelto di sperimentare i modelli di base LLM con l'architettura BERT per mettere a punto un classificatore linguistico tossico. Sono stati testati un totale di tre modelli dall'hub modello di Hugging Face:

Tutte e tre le architetture del modello sono basate su BERTweet architettura. BERTweet è addestrato in base al RoBERta procedura di pre-formazione. La procedura di pre-addestramento RoBERTa è il risultato di uno studio di replica del pre-addestramento BERT che ha valutato gli effetti dell'ottimizzazione degli iperparametri e della dimensione del set di addestramento per migliorare la ricetta per l'addestramento dei modelli BERT⁶ (Liù 2019). L'esperimento ha cercato di trovare un metodo di pre-addestramento che migliorasse i risultati delle prestazioni di BERT senza modificare l'architettura sottostante. La conclusione dello studio ha rilevato che le seguenti modifiche pre-formazione hanno sostanzialmente migliorato le prestazioni del BERT:

• Addestramento del modello con batch più grandi su più dati
• Rimozione dell'obiettivo di previsione della frase successiva
• Allenamento su sequenze più lunghe
• Modifica dinamica del modello di mascheramento applicato ai dati di addestramento

Il modello base bertweet utilizza la precedente procedura di pre-addestramento dello studio RoBERTa per pre-addestrare l'architettura BERT originale utilizzando 850 milioni di tweet in inglese. È il primo modello linguistico pubblico su larga scala pre-addestrato per i tweet in inglese.

Si pensava che gli FM pre-addestrati che utilizzavano i tweet si adattassero al caso d'uso per due ragioni teoriche principali:

• La lunghezza di un tweet è molto simile alla lunghezza di una frase inappropriata o tossica trovata nelle chat di gioco online
• I tweet provengono da una popolazione con una grande varietà di utenti diversi, simile a quella che si trova nelle piattaforme di gioco

AWS ha deciso di mettere a punto BERTweet con i dati etichettati del cliente per ottenere una linea di base. Quindi ha scelto di mettere a punto altri due FM in bertweet-base-offensive e bertweet-base-hate che sono stati ulteriormente pre-addestrati specificamente su tweet tossici più rilevanti per ottenere una precisione potenzialmente maggiore. Il modello bertweet-base-offensive utilizza il BertTweet FM di base ed è ulteriormente pre-addestrato su 14,100 tweet con annotazioni ritenuti offensivi⁷ (Zampieri 2019). Il modello bertweet-base-hate utilizza anche il BertTweet FM di base, ma è ulteriormente pre-addestrato su 19,600 tweet considerati incitamento all'odio⁸ (Basilio 2019).

Per migliorare ulteriormente le prestazioni del modello PoC, AWS GAIIC ha preso due decisioni di progettazione:

• Creato un flusso di previsione in due fasi in cui il primo modello funge da classificatore binario che classifica se una parte di testo è tossica o non tossica. Il secondo modello è un modello a grana fine che classifica il testo in base ai tipi di sostanze tossiche definiti dal cliente. Solo se il primo modello prevede che il testo sia tossico, viene passato al secondo modello.
• Aumentati i dati di addestramento e aggiunto un sottoinsieme di un set di dati di testo tossico etichettato da terze parti da una competizione pubblica di Kaggle (Tossicità del puzzle) ai 100 campioni originali ricevuti dal cliente. Hanno mappato le etichette Jigsaw alle etichette di tossicità associate definite dal cliente e hanno suddiviso l'80% come dati di addestramento e il 20% come dati di test per convalidare il modello.

AWS GAIIC utilizzato Amazon Sage Maker notebook per eseguire i loro esperimenti di messa a punto e hanno scoperto che il modello bertweet-base-offensive ha ottenuto i punteggi migliori nel set di convalida. La tabella seguente riassume i punteggi delle metriche osservati.

Da questo punto, GAIIC ha consegnato il PoC al team di consegna ML di AWS ProServe per produrre il PoC.

Soluzione AWS ProServe ML Delivery Team

Per produrre l'architettura del modello, il cliente ha chiesto al team di consegna ML di AWS ProServe (MLDT) di creare una soluzione scalabile e di facile manutenzione. Ci sono state alcune sfide di manutenzione di un approccio modello a due fasi:

• I modelli richiederebbero il doppio della quantità di monitoraggio del modello, il che rende i tempi di riaddestramento incoerenti. Potrebbero esserci momenti in cui un modello dovrà essere riqualificato più spesso dell'altro.
• Aumento dei costi di gestione di due modelli rispetto a uno.
• La velocità dell'inferenza rallenta perché l'inferenza passa attraverso due modelli.

Per affrontare queste sfide, AWS ProServe MLDT ha dovuto capire come trasformare l'architettura del modello a due fasi in un'architettura a modello singolo pur mantenendo la precisione dell'architettura a due fasi.

La soluzione era chiedere prima al cliente più dati di addestramento, quindi mettere a punto il modello bertweet-base-offensivo su tutte le etichette, inclusi i campioni non tossici, in un unico modello. L'idea era che la messa a punto di un modello con più dati avrebbe prodotto risultati simili alla messa a punto di un'architettura del modello a due fasi con meno dati. Per ottimizzare l'architettura del modello a due fasi, AWS ProServe MLDT ha aggiornato l'intestazione di classificazione multi-etichetta del modello pre-addestrato per includere un nodo aggiuntivo per rappresentare la classe non tossica.

Di seguito è riportato un esempio di codice di come mettere a punto un modello pre-addestrato dall'hub del modello Hugging Face utilizzando la piattaforma dei trasformatori e modificare l'intestazione di classificazione multi-etichetta del modello per prevedere il numero desiderato di classi. AWS ProServe MLDT ha utilizzato questo progetto come base per la messa a punto. Presuppone che tu abbia i dati del treno e i dati di convalida pronti e nel formato di input corretto.

Innanzitutto, vengono importati i moduli Python e il modello pre-addestrato desiderato dall'hub del modello 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)

Il modello pre-addestrato viene quindi caricato e preparato per la messa a punto. Questo è il passaggio in cui vengono definiti il ​​numero di categorie tossiche e tutti i parametri del modello:

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

La messa a punto del modello inizia con l'inserimento dei percorsi nei set di dati di addestramento e convalida:

# 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 ha ricevuto circa 5,000 campioni di dati etichettati in più, 3,000 non tossici e 2,000 tossici, e ha perfezionato tutti e tre i modelli basati su bertweet, combinando tutte le etichette in un unico modello. Hanno utilizzato questi dati in aggiunta ai 5,000 campioni del PoC per mettere a punto nuovi modelli a uno stadio utilizzando lo stesso set di treni all'80%, set di test al 20%. La tabella seguente mostra che i punteggi delle prestazioni erano paragonabili a quelli del modello a due stadi.

L'approccio del modello a una fase ha consentito di migliorare i costi e la manutenzione riducendo la precisione solo del 3%. Dopo aver soppesato i compromessi, il cliente ha optato per AWS ProServe MLDT per produrre il modello a una fase.

Ottimizzando un modello con più dati etichettati, AWS ProServe MLDT è stato in grado di fornire una soluzione che soddisfaceva la soglia del cliente per l'accuratezza del modello, oltre a soddisfare la richiesta di facilità di manutenzione, riducendo al contempo i costi e aumentando la robustezza.

Conclusione

Un grande cliente di giochi stava cercando un modo per rilevare il linguaggio tossico all'interno dei propri canali di comunicazione per promuovere un ambiente di gioco socialmente responsabile. AWS GAIIC ha creato un PoC di un rilevatore di linguaggio tossico mettendo a punto un LLM per rilevare il linguaggio tossico. AWS ProServe MLDT ha quindi aggiornato il flusso di addestramento del modello da un approccio a due fasi a un approccio a una fase e ha prodotto l'LLM affinché il cliente lo utilizzasse su larga scala.

In questo post, AWS dimostra l'efficacia e la praticità della messa a punto di un LLM per risolvere questo caso d'uso del cliente, condivide il contesto sulla storia dei modelli di base e degli LLM e introduce il flusso di lavoro tra AWS Generative AI Innovation Center e AWS ProServe ML Squadra di consegna. Nel prossimo post di questa serie, approfondiremo il modo in cui AWS ProServe MLDT ha prodotto il modello a una fase risultante utilizzando SageMaker.

Se sei interessato a lavorare con AWS per creare una soluzione di intelligenza artificiale generativa, contatta il GAIC. Valuteranno il tuo caso d'uso, creeranno un proof of concept basato sull'IA generativa e avranno opzioni per estendere la collaborazione con AWS per implementare il PoC risultante in produzione.

Riferimenti

1. Dati demografici dei giocatori: fatti e statistiche sull'hobby più popolare al mondo
2. ChatGPT stabilisce il record per la base di utenti in più rapida crescita - nota dell'analista
3. Vaswani et al., "L'attenzione è tutto ciò di cui hai bisogno"
4. Radford et al., "Miglioramento della comprensione del linguaggio grazie al pre-addestramento generativo"
5. Devlin et al., "BERT: pre-formazione di trasformatori bidirezionali profondi per la comprensione del linguaggio"
6. Yinhan Liu et al., "RoBERTa: un approccio di pre-formazione BERT fortemente ottimizzato"
7. Marcos Zampieri et al., "SemEval-2019 Task 6: Identificare e classificare il linguaggio offensivo nei social media (OffensEval)"
8. Valerio Basile et al., “SemEval-2019 Task 5: Rilevazione multilingue di discorsi di odio contro immigrati e donne su Twitter”

Circa gli autori

Giacomo Poquiz è un Data Scientist presso AWS Professional Services con sede a Orange County, California. Ha una laurea in Informatica presso l'Università della California, Irvine e ha diversi anni di esperienza lavorativa nel dominio dei dati avendo ricoperto molti ruoli diversi. Oggi si occupa dell'implementazione e della distribuzione di soluzioni ML scalabili per ottenere risultati di business per i clienti AWS.

L'uomo Han è un Senior Data Science & Machine Learning Manager con AWS Professional Services con sede a San Diego, CA. Ha conseguito un dottorato di ricerca in ingegneria presso la Northwestern University e ha diversi anni di esperienza come consulente di gestione fornendo consulenza ai clienti nel settore manifatturiero, dei servizi finanziari e dell'energia. Oggi lavora con passione con clienti chiave di una varietà di settori verticali per sviluppare e implementare soluzioni ML e GenAI su AWS.

Safa Tinaztepe è un data scientist full-stack con AWS Professional Services. Ha conseguito una laurea in informatica presso la Emory University e ha interessi in MLOps, sistemi distribuiti e web3.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Automobilistico/VE, Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• BlockOffset. Modernizzare la proprietà della compensazione ambientale. Accedi qui.
• 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/