AWS esegue il fine-tuning su un Large Language Model (LLM) per classificare il discorso tossico per una grande azienda di videogiochi

AWS fa fine-tuning su un LLM per classificare discorso tossico per un'azienda di videogiochi

L’industria dei videogiochi ha una base utenti stimata di oltre 3 miliardi in tutto il mondo1. Essa consiste in una grande quantità di giocatori che interagiscono virtualmente tra loro ogni giorno. Purtroppo, come nel mondo reale, non tutti i giocatori comunicano in modo appropriato e rispettoso. Nell’ambito degli sforzi per creare e mantenere un ambiente di gioco socialmente responsabile, AWS Professional Services è stato incaricato di costruire un meccanismo che rilevi linguaggio inappropriato (discorsi tossici) nelle interazioni tra i giocatori online. L’obiettivo generale era migliorare le operazioni dell’organizzazione automatizzando un processo manuale esistente e migliorare l’esperienza dell’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 quella di creare un rilevatore di lingua inglese che classifichi estratti vocali e testuali in categorie di linguaggio tossico personalizzate. Volevano prima determinare se l’estratto di linguaggio fornito fosse tossico e poi classificarlo in una specifica categoria di tossicità definita dal cliente, come oscenità 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). Il GAIIC di AWS è un gruppo all’interno di AWS ProServe che mette in contatto i clienti con esperti per sviluppare soluzioni AI generative per una vasta gamma di casi d’uso aziendali utilizzando costruzioni di prova di concetto (PoC). Il team di consegna ML di AWS ProServe quindi porta il PoC in produzione, scalando, migliorando e integrando la soluzione per il cliente.

Questo caso d’uso del cliente sarà presentato in due post separati. Questo post (Parte 1) serve come approfondimento della metodologia scientifica. Esso spiegherà il processo di pensiero e sperimentazione dietro la soluzione, inclusa la formazione del modello e il processo di sviluppo. La Parte 2 approfondirà la soluzione in produzione, spiegando le decisioni di progettazione, il flusso dei dati e l’illustrazione dell’architettura di formazione e distribuzione del modello.

• Creazione di una mappa topografica del Nepal utilizzando Python
• Gli esperti tecnici iniziano a dubitare che ChatGPT, le ‘allucinazioni’ dell’intelligenza artificiale, scompariranno mai
• L’urgente necessità di un uso responsabile dell’IA generativa

Questo post copre i seguenti argomenti:

• Le sfide affrontate da AWS ProServe per questo caso d’uso
• Contesto storico sui modelli di linguaggio ampi (LLM) e perché questa tecnologia è perfetta per questo caso d’uso
• Il PoC di AWS GAIIC e la soluzione di AWS ProServe MLDT da una prospettiva di scienza dei dati e machine learning (ML)

Sfida dei dati

La principale sfida affrontata da AWS ProServe nella formazione di un classificatore di linguaggio tossico era ottenere dati etichettati sufficienti dal cliente per addestrare un modello accurato da zero. AWS ha ricevuto circa 100 campioni di dati etichettati dal cliente, che è molto meno dei 1.000 campioni consigliati per il perfezionamento di un LLM nella comunità della scienza dei dati.

Come ulteriore sfida intrinseca, i classificatori di elaborazione del linguaggio naturale (NLP) sono storicamente noti per essere molto costosi da addestrare e richiedono un ampio insieme di vocabolario, noto come corpus, per produrre previsioni accurate. Una soluzione rigorosa ed efficace di NLP, se fornita una quantità sufficiente di dati etichettati, sarebbe quella di addestrare un modello di linguaggio personalizzato utilizzando i dati etichettati del cliente. Il modello sarebbe addestrato esclusivamente con il vocabolario di gioco dei giocatori, rendendolo adatto al linguaggio osservato nei giochi. Il cliente aveva vincoli di costo e tempo che rendevano questa soluzione non fattibile. AWS ProServe è stato costretto a trovare una soluzione per addestrare un classificatore di tossicità del linguaggio accurato con un set di dati etichettati relativamente piccolo. La soluzione risiedeva in ciò che è noto come trasferimento di apprendimento.

L’idea di base del trasferimento di apprendimento è 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 predire se un’immagine contiene un gatto, è possibile utilizzare la conoscenza che il modello ha acquisito durante il suo addestramento per riconoscere altri animali come tigri. Per questo caso d’uso del linguaggio, AWS ProServe doveva trovare un classificatore di linguaggio pre-addestrato che fosse stato addestrato per rilevare il linguaggio tossico e affinarlo utilizzando i dati etichettati del cliente.

La soluzione è stata quella di trovare e perfezionare un LLM per classificare il linguaggio tossico. I LLM sono reti neurali che sono state addestrate utilizzando un’ampia quantità di parametri, tipicamente nell’ordine dei miliardi, utilizzando dati non etichettati. Prima di entrare nella soluzione AWS, la seguente sezione fornisce una panoramica sulla storia dei LLM e dei loro casi d’uso storici.

Sfruttare il potere dei LLM

I LLM sono diventati di recente il punto focale per le aziende alla ricerca di nuove applicazioni di ML, da quando ChatGPT ha catturato l’attenzione del pubblico diventando l’applicazione consumer a più rapida crescita nella storia2, raggiungendo 100 milioni di utenti attivi entro gennaio 2023, solo 2 mesi dopo il suo rilascio. Tuttavia, i LLM non sono una nuova tecnologia nello spazio del ML. Sono stati utilizzati ampiamente per svolgere compiti di NLP come analisi del sentimento, sintesi di corpuses, estrazione di parole chiave, traduzione del linguaggio, e classificazione del testo.

A causa della natura sequenziale del testo, le reti neurali ricorrenti (RNN) sono state lo stato dell’arte per la modellazione NLP. In particolare, l’architettura di rete encoder-decoder è stata formulata perché creava una struttura RNN in grado di prendere in input una lunghezza arbitraria e generare un output di lunghezza arbitraria. Questo era ideale per compiti NLP come la traduzione in cui una frase di output di una lingua poteva essere prevista da una frase di input di un’altra lingua, di solito con un numero diverso di parole tra l’input e l’output. L’architettura Transformer (Vaswani, 2017) è stata un miglioramento rivoluzionario dell’encoder-decoder; ha introdotto il concetto di self-attention, che ha permesso al modello di concentrare la sua attenzione su diverse parole delle frasi di input e output. In un tipico encoder-decoder, ogni parola viene interpretata dal modello in modo identico. Man mano che il modello elabora sequenzialmente ogni parola di una frase di input, le informazioni semantiche all’inizio potrebbero essere perse alla fine della frase. Il meccanismo di self-attention ha cambiato questo aggiungendo uno strato di attenzione sia al blocco dell’encoder che al blocco del decoder, in modo che il modello potesse dare diversi pesi a determinate parole della frase di input quando generava una determinata parola nella frase di output. Così è nato il modello Transformer.

L’architettura Transformer è stata la base per due dei modelli LLM più noti e popolari utilizzati oggi, ovvero il 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 elemento della ricetta che rende i LLM così potenti è la capacità di estrarre informazioni da vasti corpus di testo senza etichettatura o preprocessing estensivo attraverso un processo chiamato ULMFiT. Questo metodo ha una fase di pre-training in cui è possibile raccogliere testo generale e il modello viene addestrato al compito di prevedere la parola successiva basandosi sulle parole precedenti; il vantaggio qui è che qualsiasi testo di input utilizzato per l’addestramento viene etichettato in modo predefinito in base all’ordine del testo. I LLM sono veramente capaci di imparare da dati di scala Internet. Ad esempio, il modello BERT originale è stato pre-addestrato sui dataset BookCorpus e l’intero testo dell’enciclopedia Wikipedia in inglese.

Questa nuova modalità di modellazione ha dato origine a due nuovi concetti: i modelli di base (FMs) e l’IA generativa. Al contrario dell’addestramento di un modello da zero con dati specifici del compito, che è il caso usuale per l’apprendimento supervisionato classico, i LLM vengono pre-addestrati per estrarre conoscenze generali da un ampio dataset di testo prima di essere adattati a compiti o domini specifici con un dataset molto più piccolo (tipicamente nell’ordine delle centinaia di campioni). Il nuovo flusso di lavoro di apprendimento automatico inizia ora con un modello pre-addestrato chiamato modello di base. È importante costruire sulla base giusta e ci sono sempre più opzioni, come i nuovi modelli Amazon Titan FMs, che saranno rilasciati da AWS come parte di Amazon Bedrock. Questi nuovi modelli sono anche considerati generativi perché i loro output sono interpretabili dall’essere umano e dello stesso tipo di dati in input. Mentre i modelli di apprendimento automatico del passato erano descrittivi, come la classificazione di immagini di gatti vs cani, i LLM sono generativi perché il loro output è il prossimo insieme di parole basato sulle parole in input. Ciò consente loro di alimentare applicazioni interattive come ChatGPT che possono esprimere il contenuto che generano.

Hugging Face ha stretto una partnership con AWS per democratizzare i modelli di base e renderli facili da accedere e utilizzare. Hugging Face ha creato un’API di Transformer che unifica più di 50 diverse architetture di Transformer su diversi framework di apprendimento automatico, inclusi l’accesso ai pesi dei modelli pre-addestrati nel loro Model Hub, che è cresciuto fino a oltre 200.000 modelli al momento della stesura di questo post. Nelle sezioni successive, esploreremo la prova di concetto, la soluzione e i modelli di base che sono stati testati e scelti come base per risolvere questo caso d’uso di classificazione del discorso tossico per il cliente.

Prova di concetto AWS GAIIC

AWS GAIIC ha scelto di sperimentare con i modelli di base LLM con l’architettura BERT per ottimizzare un classificatore di lingua tossica. Sono stati testati in totale tre modelli dal model hub di Hugging Face:

• vinai/bertweet-base
• cardiffnlp/bertweet-base-offensive
• cardiffnlp/bertweet-base-hate

Tutte e tre le architetture dei modelli si basano sull’architettura BERTweet. BERTweet è addestrato sulla base della procedura di pre-addestramento RoBERTa. La procedura di pre-addestramento RoBERTa è il risultato di uno studio di replicazione 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 (Liu 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 al pre-addestramento hanno migliorato sostanzialmente le prestazioni di BERT:

• Allenare il modello con batch più grandi su più dati
• Rimuovere l’obiettivo di previsione della frase successiva
• Allenarsi su sequenze più lunghe
• Cambiare dinamicamente il modello di mascheramento applicato ai dati di allenamento

Il modello bertweet-base utilizza la procedura di pre-training precedente dello studio RoBERTa per pre-allenare l’architettura originale di BERT utilizzando 850 milioni di tweet in inglese. È il primo modello di linguaggio su larga scala pre-allenato pubblicamente per i tweet in inglese.

I FMs pre-allenati utilizzando i tweet sono stati ritenuti adatti 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 della popolazione trovata nelle piattaforme di gioco

AWS ha deciso di regolare BERTweet inizialmente con i dati etichettati del cliente per ottenere una base di partenza. Poi ha scelto di regolare ulteriormente altri due FMs in bertweet-base-offensive e bertweet-base-hate che sono stati ulteriormente pre-allenati specificamente su tweet tossici più rilevanti per ottenere potenzialmente una maggiore precisione. Il modello bertweet-base-offensive utilizza il FM di base di BertTweet ed è ulteriormente pre-allenato su 14.100 tweet annotati che sono stati considerati offensivi7 (Zampieri 2019). Il modello bertweet-base-hate utilizza anche il FM di base di BertTweet, ma è ulteriormente pre-allenato su 19.600 tweet che sono stati considerati discorso d’odio8 (Basile 2019).

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

• Ha creato un flusso di previsione a due fasi in cui il primo modello agisce come un classificatore binario che classifica se un pezzo di testo è tossico o non tossico. Il secondo modello è un modello a grana fine che classifica il testo in base ai tipi di tossicità definiti dal cliente. Solo se il primo modello prevede il testo come tossico, viene passato al secondo modello.
• Ha aumentato i dati di allenamento e aggiunto un sottoinsieme di un dataset di testo tossico etichettato di terze parti da una competizione pubblica Kaggle (Jigsaw Toxicity) ai 100 campioni originali ricevuti dal cliente. Hanno mappato le etichette Jigsaw alle etichette di tossicità associate definite dal cliente e hanno effettuato una divisione dell’80% come dati di allenamento e una divisione del 20% come dati di test per convalidare il modello.

AWS GAIIC ha utilizzato i notebook di Amazon SageMaker per eseguire i loro esperimenti di regolazione fine e ha scoperto che il modello bertweet-base-offensive ha ottenuto i migliori punteggi sul set di convalida. La tabella seguente riassume i punteggi metrici osservati.

Modello	Precisione	Recall	F1	AUC
Binario	.92	.90	.91	.92
A grana fine	.81	.80	.81	.89

Da questo punto, GAIIC ha affidato il PoC al team di consegna ML di AWS ProServe per la messa in produzione del PoC.

Soluzione del team di consegna ML di AWS ProServe

Per mettere in produzione l’architettura del modello, il team di consegna ML di AWS ProServe (MLDT) è stato incaricato dal cliente di creare una soluzione scalabile e facile da mantenere. Ci sono state alcune sfide di manutenzione di un approccio a due fasi del modello:

• I modelli richiederebbero il doppio del monitoraggio del modello, il che rende il tempo di riallenamento inconsistente. Potrebbe accadere che un modello debba essere riallenato più spesso dell’altro.
• Aumento dei costi di esecuzione di due modelli anziché uno.
• La velocità di 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 di un singolo modello pur mantenendo l’accuratezza dell’architettura a due fasi.

La soluzione è stata quella di chiedere inizialmente al cliente più dati di addestramento, quindi di perfezionare il modello bertweet-base-offensive su tutte le etichette, compresi i campioni non tossici, in un unico modello. L’idea era che il perfezionamento di un modello con più dati avrebbe prodotto risultati simili al perfezionamento di un’architettura di un modello a due fasi con meno dati. Per perfezionare l’architettura del modello a due fasi, AWS ProServe MLDT ha aggiornato la testa di classificazione multi-etichetta del modello pre-addestrato per includere un nodo extra per rappresentare la classe non tossica.

Di seguito è riportato un esempio di codice su come perfezionare un modello pre-addestrato dal model hub di Hugging Face utilizzando la loro piattaforma transformers e modificare la testa di classificazione multi-etichetta del modello per prevedere il numero desiderato di classi. AWS ProServe MLDT ha utilizzato questa base per il perfezionamento. Si presume che i dati di addestramento e di convalida siano pronti e nel formato di input corretto.

Innanzitutto, vengono importati i moduli Python e il modello pre-addestrato desiderato dal model hub di Hugging Face:

# Importazioni.
from transformers import (
    AutoModelForSequenceClassification,
    AutoTokenizer,
    DataCollatorWithPadding,
    PreTrainedTokenizer,
    Trainer,
    TrainingArguments,
)

# Carica il modello pre-addestrato dal model hub in un tokenizer.
model_checkpoint = "cardiffnlp/bertweet-base-offensive"
tokenizer = AutoTokenizer.from_pretrained(checkpoint)

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

# Carica il modello pre-addestrato in un classificatore di sequenze da perfezionare e definisci il numero di classi da classificare nel parametro num_labels.

model = AutoModelForSequenceClassification.from_pretrained(
            model_checkpoint,
            num_labels=[numero di classi]
        )

# Imposta i parametri di addestramento. Di seguito sono riportati alcuni parametri chiave che AWS ProServe MLDT ha regolato:
training_args = TrainingArguments(
        num_train_epochs=[inserisci input]
        per_device_train_batch_size=[inserisci input]
        per_device_eval_batch_size=[inserisci input]
        evaluation_strategy="epoch",
        logging_strategy="epoch",
        save_strategy="epoch",
        learning_rate=[inserisci input]
        load_best_model_at_end=True,
        metric_for_best_model=[inserisci input]
        optim=[inserisci input],
    )

Il perfezionamento del modello inizia con l’inserimento dei percorsi per i dataset di addestramento e di convalida:

# Perfeziona il modello dal model_checkpoint, tokenizer e training_args definiti assumendo che i dataset di addestramento e di convalida siano correttamente preprocessati.
trainer = Trainer(
        model=model,
        args=training_args,
        train_dataset=[inserisci input],
        eval_dataset=[inserisci input],
        tokenizer=tokenizer,
        data_collator=data_collator,
    )

# Comando per il perfezionamento del modello.
trainer.train()

AWS ProServe MLDT ha ricevuto circa 5.000 campioni di dati etichettati in più, di cui 3.000 non tossici e 2.000 tossici, e ha perfezionato tutti e tre i modelli bertweet-base, combinando tutte le etichette in un unico modello. Hanno utilizzato questi dati oltre ai 5.000 campioni provenienti dalla PoC per perfezionare nuovi modelli in una fase utilizzando il metodo dell’80% di set di addestramento e del 20% di set di test. La seguente tabella mostra che i punteggi di prestazione erano comparabili a quelli del modello a due fasi.

Modello	Precisione	Recall	F1	AUC
bertweet-base (1 fase)	0,76	0,72	0,74	0,83
bertweet-base-hate (1 fase)	0,85	0,82	0,84	0,87
bertweet-base-offensive (1 fase)	0,88	0,83	0,86	0,89
bertweet-base-offensive (2 fasi)	0,91	0,90	0,90	0,92

L’approccio del modello in un’unica fase ha portato miglioramenti in termini di costi e manutenzione, riducendo solo del 3% la precisione. Dopo aver valutato i compromessi, il cliente ha scelto AWS ProServe MLDT per mettere in produzione il modello in un’unica fase.

Attraverso il raffinamento di un modello con ulteriori dati etichettati, AWS ProServe MLDT è stato in grado di fornire una soluzione che soddisfacesse la soglia di accuratezza del modello richiesta dal cliente, garantendo al contempo facilità di manutenzione, riduzione dei costi e maggiore robustezza.

Conclusioni

Un grande cliente nel settore dei giochi stava cercando un modo per rilevare linguaggio tossico all’interno dei propri canali di comunicazione al fine di promuovere un ambiente di gioco socialmente responsabile. AWS GAIIC ha creato una PoC di un rilevatore di linguaggio tossico attraverso il raffinamento di un LLM per rilevare linguaggio tossico. Successivamente, AWS ProServe MLDT ha aggiornato il flusso di addestramento del modello passando da un approccio a due fasi a un approccio a una fase e ha messo in produzione il LLM per il cliente, consentendone l’utilizzo su larga scala.

In questo articolo, AWS dimostra l’efficacia e la praticità del raffinamento di un LLM per risolvere questo caso d’uso del cliente, condivide il contesto sulla storia dei modelli di base e dei LLM e presenta il flusso di lavoro tra il Centro di Innovazione AI Generativa AWS e il Team di Consegna AWS ProServe ML. Nel prossimo articolo di questa serie, approfondiremo come AWS ProServe MLDT abbia messo in produzione il modello in un’unica fase risultante utilizzando SageMaker.

Se sei interessato a lavorare con AWS per sviluppare una soluzione di Intelligenza Artificiale Generativa, ti invitiamo a contattare il GAIIC. Saranno valutati il tuo caso d’uso, verrà sviluppata una prova di concetto basata su AI generativa e avrai la possibilità di collaborare con AWS per implementare la PoC risultante in produzione.

Riferimenti

1. Demografia dei giocatori: Fatti e statistiche sul passatempo più popolare al mondo
2. ChatGPT batte il record per la crescita più rapida della base utenti – nota dell’analista
3. Vaswani et al., “Attention is All You Need”
4. Radford et al., “Miglioramento della comprensione del linguaggio tramite pre-addestramento generativo”
5. Devlin et al., “BERT: Pre-Training di trasformatori bidirezionali profondi per la comprensione del linguaggio”
6. Yinhan Liu et al., “RoBERTa: Un approccio di pre-addestramento BERT robustamente ottimizzato”
7. Marcos Zampieri et al., “SemEval-2019 Task 6: Identificazione e categorizzazione del linguaggio offensivo sui social media (OffensEval)”
8. Valerio Basile et al., “SemEval-2019 Task 5: Rilevamento multilingue di discorsi d’odio contro gli immigrati e le donne su Twitter”