AWS przeprowadza precyzyjne dostrajanie modelu dużego języka (LLM) w celu sklasyfikowania toksycznej mowy dla dużej firmy zajmującej się grami | Usługi sieciowe Amazona

Branża gier wideo ma szacowaną bazę użytkowników na ponad 3 miliardy na całym świecie¹. Składa się z ogromnej liczby graczy, którzy wirtualnie wchodzą ze sobą w interakcje każdego dnia. Niestety, podobnie jak w prawdziwym świecie, nie wszyscy gracze komunikują się odpowiednio i z szacunkiem. W celu stworzenia i utrzymania społecznie odpowiedzialnego środowiska gier, firma AWS Professional Services została poproszona o zbudowanie mechanizmu wykrywającego nieodpowiedni język (toksyczną mowę) w interakcjach graczy online. Ogólnym rezultatem biznesowym było usprawnienie operacji organizacji poprzez automatyzację istniejącego ręcznego procesu oraz poprawę doświadczenia użytkownika poprzez zwiększenie szybkości i jakości wykrywania niewłaściwych interakcji między graczami, co ostatecznie przyczyniło się do promowania czystszego i zdrowszego środowiska gier.

Klient poprosił o stworzenie detektora języka angielskiego, który klasyfikuje fragmenty głosu i tekstu do własnych, niestandardowych, zdefiniowanych toksycznych kategorii językowych. Chcieli najpierw ustalić, czy dany fragment językowy jest toksyczny, a następnie sklasyfikować fragment w określonej kategorii toksyczności zdefiniowanej przez klienta, takiej jak wulgaryzmy lub obraźliwy język.

AWS ProServe rozwiązał ten przypadek użycia dzięki wspólnym wysiłkom Generative AI Innovation Center (GAIIC) i ProServe ML Delivery Team (MLDT). AWS GAIIC to grupa w ramach AWS ProServe, która łączy klientów z ekspertami w celu opracowania generatywnych rozwiązań AI dla szerokiego zakresu przypadków użycia biznesowego przy użyciu kompilacji Proof of Concept (PoC). Następnie AWS ProServe MLDT przeprowadza PoC przez proces produkcyjny, skalując, utwardzając i integrując rozwiązanie dla klienta.

Ten przypadek użycia klienta zostanie przedstawiony w dwóch osobnych postach. Ten post (część 1) służy jako głębokie zagłębienie się w metodologię naukową. Wyjaśni proces myślowy i eksperymenty stojące za rozwiązaniem, w tym proces uczenia i opracowywania modeli. Część 2 zagłębi się w produkcyjne rozwiązanie, wyjaśniając decyzje projektowe, przepływ danych i ilustrując model szkolenia i architektury wdrażania.

Ten post obejmuje następujące tematy:

• Wyzwania, które AWS ProServe musiało rozwiązać w tym przypadku użycia
• Kontekst historyczny dotyczący dużych modeli językowych (LLM) i dlaczego ta technologia idealnie pasuje do tego przypadku użycia
• Rozwiązanie AWS GAIIC PoC i AWS ProServe MLDT z perspektywy nauki o danych i uczenia maszynowego (ML)

Wyzwanie dotyczące danych

Głównym wyzwaniem, przed którym stanął AWS ProServe podczas szkolenia klasyfikatora toksycznego języka, było uzyskanie od klienta wystarczającej ilości oznakowanych danych, aby wytrenować dokładny model od podstaw. AWS otrzymał od klienta około 100 próbek oznaczonych danych, czyli o wiele mniej niż 1,000 próbek zalecanych do dostrajania LLM w społeczności analityków danych.

Jako dodatkowe nieodłączne wyzwanie, klasyfikatory przetwarzania języka naturalnego (NLP) są historycznie znane jako bardzo kosztowne w szkoleniu i wymagają dużego zestawu słownictwa, znanego jako ciało, aby uzyskać dokładne prognozy. Rygorystyczne i skuteczne rozwiązanie NLP, jeśli zapewniłoby wystarczającą ilość danych z etykietami, polegałoby na trenowaniu niestandardowego modelu językowego przy użyciu danych z etykietami klienta. Model byłby szkolony wyłącznie ze słownictwa graczy, dzięki czemu byłby dostosowany do języka obserwowanego w grach. Klient miał zarówno ograniczenia finansowe, jak i czasowe, które sprawiły, że to rozwiązanie było nieopłacalne. AWS ProServe został zmuszony do znalezienia rozwiązania umożliwiającego wytrenowanie dokładnego klasyfikatora toksyczności językowej ze stosunkowo niewielkim zbiorem danych z etykietami. Rozwiązanie leżało w tzw przenieś naukę.

Ideą nauczania transferowego jest wykorzystanie wiedzy z wcześniej wytrenowanego modelu i zastosowanie jej do innego, ale względnie podobnego problemu. Na przykład, jeśli klasyfikator obrazów został przeszkolony w zakresie przewidywania, czy obraz zawiera kota, można wykorzystać wiedzę zdobytą podczas uczenia modelu do rozpoznawania innych zwierząt, takich jak tygrysy. W tym przypadku użycia języka AWS ProServe musiał znaleźć wcześniej przeszkolony klasyfikator języka, który został przeszkolony w zakresie wykrywania toksycznego języka i dostrajania go przy użyciu oznaczonych danych klienta.

Rozwiązaniem było znalezienie i dostrojenie LLM w celu sklasyfikowania toksycznego języka. LLM to sieci neuronowe, które zostały wytrenowane przy użyciu ogromnej liczby parametrów, zwykle rzędu miliardów, przy użyciu nieoznakowanych danych. Zanim przejdziemy do rozwiązania AWS, poniższa sekcja zawiera przegląd historii LLM i ich historycznych przypadków użycia.

Wykorzystanie mocy LLM

LLM stały się ostatnio centralnym punktem dla firm poszukujących nowych zastosowań ML, odkąd ChatGPT zdobył opinię publiczną, będąc najszybciej rozwijającą się aplikacją konsumencką w historii², osiągając 100 milionów aktywnych użytkowników do stycznia 2023 r., zaledwie 2 miesiące po premierze. Jednak LLM nie są nową technologią w przestrzeni ML. Były szeroko stosowane do wykonywania zadań NLP, takich jak analiza nastrojów, podsumowywanie korpusów, wydobywanie słów kluczowych, tłumaczenie mowy i klasyfikowanie tekstu.

Ze względu na sekwencyjny charakter tekstu rekurencyjne sieci neuronowe (RNN) były najnowocześniejszym modelowaniem NLP. Konkretnie, koder-dekoder architektura sieci została sformułowana, ponieważ tworzyła strukturę RNN zdolną do przyjmowania danych wejściowych o dowolnej długości i generowania danych wyjściowych o dowolnej długości. Było to idealne rozwiązanie w przypadku zadań NLP, takich jak tłumaczenie, w przypadku których frazę wyjściową jednego języka można było przewidzieć na podstawie frazy wejściowej innego języka, zwykle z różną liczbą słów między wejściem a wyjściem. Architektura transformatora³ (Vaswani, 2017) było przełomowym ulepszeniem kodera-dekodera; wprowadził pojęcie samokontrola, co pozwoliło modelowi skupić swoją uwagę na różnych słowach na frazach wejściowych i wyjściowych. W typowym koderze-dekoderze każde słowo jest interpretowane przez model w identyczny sposób. Ponieważ model sekwencyjnie przetwarza każde słowo we frazie wejściowej, informacja semantyczna na początku może zostać utracona na końcu frazy. Mechanizm samouwagi zmienił to, dodając warstwę uwagi zarówno do bloku kodera, jak i dekodera, tak aby model mógł przypisywać różne wagi niektórym słowom z frazy wejściowej podczas generowania określonego słowa we frazie wyjściowej. W ten sposób narodziła się podstawa modelu transformatora.

Architektura transformatora była podstawą dla dwóch najbardziej znanych i popularnych obecnie używanych LLM, Bidirectional Encoder Representations from Transformers (BERT)⁴ (Radford, 2018) i generatywny wstępnie wytrenowany transformator (GPT)⁵ (Devlin 2018). Późniejsze wersje modelu GPT, a mianowicie GPT3 i GPT4, są silnikiem napędzającym aplikację ChatGPT. Ostatnim elementem przepisu, który sprawia, że ​​LLM są tak potężne, jest zdolność do destylacji informacji z ogromnych korpusów tekstowych bez obszernego etykietowania lub wstępnego przetwarzania za pomocą procesu zwanego ULMFiT. Ta metoda ma fazę przedtreningową, w której można zebrać ogólny tekst, a model jest szkolony w zakresie przewidywania następnego słowa na podstawie poprzednich słów; zaletą jest to, że każdy tekst wejściowy używany do uczenia jest z natury wstępnie oznaczony na podstawie kolejności tekstu. LLM są naprawdę zdolne do uczenia się na podstawie danych w skali internetowej. Na przykład oryginalny model BERT został wstępnie przeszkolony na zbiorach danych tekstowych BookCorpus i całej angielskiej Wikipedii.

Ten nowy paradygmat modelowania dał początek dwóm nowym koncepcjom: modele podstawowe (FM) i generatywna sztuczna inteligencja. W przeciwieństwie do uczenia modelu od podstaw z danymi specyficznymi dla zadania, co jest typowym przypadkiem klasycznego uczenia nadzorowanego, LLM są wstępnie szkolone w zakresie wydobywania wiedzy ogólnej z szerokiego zestawu danych tekstowych, zanim zostaną dostosowane do określonych zadań lub domen o znacznie mniejszym zbioru danych (zwykle rzędu setek próbek). Nowy przepływ pracy ML zaczyna się teraz od wstępnie wytrenowanego modelu zwanego modelem podstawowym. Ważne jest, aby budować na właściwym fundamencie, a dostępnych jest coraz więcej opcji, takich jak nowe Amazon Titan FM, który zostanie wydany przez AWS jako część Amazońska skała macierzysta. Te nowe modele są również uważane za generatywne, ponieważ ich wyniki są możliwe do interpretacji przez człowieka i zawierają ten sam typ danych, co dane wejściowe. Podczas gdy poprzednie modele ML były opisowe, takie jak klasyfikowanie obrazów kotów i psów, LLM są generatywne, ponieważ ich wynikiem jest kolejny zestaw słów oparty na słowach wejściowych. To pozwala im zasilać interaktywne aplikacje, takie jak ChatGPT, które mogą być wyraziste w generowanych przez siebie treściach.

Hugging Face nawiązał współpracę z AWS aby zdemokratyzować systemy FM i ułatwić do nich dostęp i korzystanie z nich. Hugging Face stworzył API transformatorów który łączy ponad 50 różnych architektur transformatorów w różnych ramach ML, w tym dostęp do wstępnie wytrenowanych wag modeli w ich Centrum modeli, która w momencie pisania tego posta rozrosła się do ponad 200,000 XNUMX modeli. W następnych sekcjach zbadamy dowód koncepcji, rozwiązanie i FM, które zostały przetestowane i wybrane jako podstawa do rozwiązania tego przypadku użycia klasyfikacji toksycznej mowy dla klienta.

Dowód koncepcji AWS GAIIC

AWS GAIIC postanowił poeksperymentować z podstawowymi modelami LLM z architekturą BERT, aby dopracować klasyfikator toksycznego języka. W sumie przetestowano trzy modele z centrum modeli Hugging Face:

Wszystkie trzy architektury modeli są oparte na BERTweet architektura. BERTweet jest szkolony w oparciu o Roberta procedura przedtreningowa. Procedura treningu wstępnego RoBERTa jest wynikiem badania replikacyjnego treningu wstępnego BERT, w którym oceniono wpływ dostrajania hiperparametrów i rozmiaru zestawu treningowego w celu ulepszenia przepisu na szkolenie modeli BERT⁶ (Liu 2019). Eksperyment miał na celu znalezienie metody przedtreningowej, która poprawi wyniki wydajności BERT bez zmiany podstawowej architektury. Wniosek z badania wykazał, że następujące modyfikacje przedtreningowe znacznie poprawiły wydajność BERT:

• Trenowanie modelu z większymi partiami na większej ilości danych
• Usunięcie celu przewidywania następnego zdania
• Trening na dłuższych sekwencjach
• Dynamiczna zmiana wzorca maskowania zastosowanego do danych treningowych

Model bertweet-base wykorzystuje poprzednią procedurę szkolenia wstępnego z badania RoBERTa do wstępnego trenowania oryginalnej architektury BERT przy użyciu 850 milionów tweetów w języku angielskim. Jest to pierwszy publiczny model językowy na dużą skalę, wstępnie wyszkolony pod kątem angielskich tweetów.

Uznano, że wstępnie przeszkolone FM używające tweetów pasują do przypadku użycia z dwóch głównych powodów teoretycznych:

• Długość tweeta jest bardzo podobna do długości nieodpowiedniej lub toksycznej frazy, którą można znaleźć na czacie w grze online
• Tweety pochodzą od populacji z dużą różnorodnością różnych użytkowników, podobnie jak populacja spotykana na platformach do gier

AWS postanowił najpierw dostroić BERTweet do danych oznaczonych przez klienta, aby uzyskać punkt odniesienia. Następnie zdecydowaliśmy się dostroić dwa inne FM w bertweet-base-offensive i bertweet-base-hate, które zostały dodatkowo przeszkolone w zakresie bardziej odpowiednich toksycznych tweetów, aby osiągnąć potencjalnie wyższą dokładność. Model bertweet-base-offensive wykorzystuje podstawowy BertTweet FM i jest dalej wstępnie szkolony na 14,100 XNUMX tweetach z adnotacjami, które zostały uznane za obraźliwe⁷ (Zampieri 2019). Model bertweet-base-hate również wykorzystuje podstawowy BertTweet FM, ale jest dalej trenowany na 19,600 XNUMX tweetach, które zostały uznane za mowę nienawiści⁸ (Bazyli 2019).

Aby jeszcze bardziej zwiększyć wydajność modelu PoC, AWS GAIIC podjął dwie decyzje projektowe:

• Utworzono dwuetapowy przepływ predykcji, w którym pierwszy model działa jako klasyfikator binarny, który klasyfikuje, czy fragment tekstu jest toksyczny, czy nie. Drugi model to drobnoziarnisty model, który klasyfikuje tekst na podstawie typów toksycznych zdefiniowanych przez klienta. Tylko wtedy, gdy pierwszy model przewiduje, że tekst jest toksyczny, przechodzi on do drugiego modelu.
• Rozszerzono dane treningowe i dodano podzbiór zestawu danych tekstowych toksycznych oznaczonych przez firmę zewnętrzną z publicznego konkursu Kaggle (Toksyczność układanki) do oryginalnych 100 próbek otrzymanych od klienta. Zmapowali etykiety Jigsaw do powiązanych etykiet toksyczności zdefiniowanych przez klienta i dokonali podziału 80% jako danych treningowych i podziału 20% jako danych testowych, aby zweryfikować model.

Zastosowano AWS GAIIC Amazon Sage Maker notebooków, aby przeprowadzić swoje eksperymenty dostrajające i odkryli, że model bertweet-base-ofensywny osiągnął najlepsze wyniki w zbiorze walidacyjnym. Poniższa tabela podsumowuje zaobserwowane wyniki metryki.

Od tego momentu GAIIC przekazał PoC zespołowi dostarczającemu AWS ProServe ML w celu wyprodukowania PoC.

Rozwiązanie AWS ProServe ML Delivery Team

Aby stworzyć architekturę modelu, zespół AWS ProServe ML Delivery Team (MLDT) został poproszony przez klienta o stworzenie skalowalnego i łatwego w utrzymaniu rozwiązania. Dwuetapowe podejście modelowe wiązało się z kilkoma wyzwaniami konserwacyjnymi:

• Modele wymagałyby podwójnego monitorowania modelu, co powoduje, że czas ponownego uczenia jest niespójny. Może się zdarzyć, że jeden model będzie musiał być przeszkolony częściej niż drugi.
• Zwiększone koszty eksploatacji dwóch modeli zamiast jednego.
• Szybkość wnioskowania spada, ponieważ wnioskowanie przechodzi przez dwa modele.

Aby sprostać tym wyzwaniom, AWS ProServe MLDT musiał wymyślić, jak przekształcić dwustopniową architekturę modelu w architekturę pojedynczego modelu, zachowując jednocześnie dokładność architektury dwustopniowej.

Rozwiązanie polegało na tym, aby najpierw poprosić klienta o więcej danych treningowych, a następnie dostroić model bertweet-base-offensive na wszystkich etykietach, w tym na nietoksycznych próbkach, w jeden model. Pomysł polegał na tym, że precyzyjne dostrojenie jednego modelu z większą liczbą danych dałoby podobne wyniki, jak dostrojenie dwuetapowej architektury modelu z mniejszą ilością danych. Aby dostroić dwuetapową architekturę modelu, AWS ProServe MLDT zaktualizował głowicę klasyfikacyjną wstępnie wytrenowanego modelu z wieloma etykietami, dodając jeden dodatkowy węzeł reprezentujący klasę nietoksyczną.

Poniżej znajduje się przykładowy kod, w jaki sposób można dostroić wstępnie wyszkolony model z centrum modelu Hugging Face przy użyciu ich platformy transformatorów i zmienić głowę klasyfikacji modelu z wieloma etykietami, aby przewidzieć żądaną liczbę klas. AWS ProServe MLDT wykorzystał ten plan jako podstawę do dopracowania. Zakłada się, że masz gotowe dane pociągu i dane walidacyjne oraz we właściwym formacie wejściowym.

Najpierw importowane są moduły Pythona, a także żądany wstępnie wytrenowany model z centrum modelu 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)

Wstępnie wyszkolony model jest następnie ładowany i przygotowywany do dostrajania. Jest to krok, w którym definiowana jest liczba kategorii toksycznych i wszystkie parametry modelu:

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

Dostrajanie modelu rozpoczyna się od wprowadzenia ścieżek do zbiorów danych szkoleniowych i walidacyjnych:

# 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 otrzymało około 5,000 więcej oznaczonych próbek danych, z których 3,000 było nietoksycznych, a 2,000 toksycznych, i dostroiło wszystkie trzy modele bazowe bertweet, łącząc wszystkie etykiety w jeden model. Wykorzystali te dane oprócz 5,000 próbek z PoC, aby dostroić nowe modele jednoetapowe przy użyciu tej samej metody 80% zestawu pociągów, 20% zestawu testów. Poniższa tabela pokazuje, że wyniki wydajności były porównywalne z wynikami modelu dwuetapowego.

Jednoetapowe podejście modelowe przyniosło poprawę w zakresie kosztów i konserwacji, jednocześnie zmniejszając precyzję jedynie o 3%. Po rozważeniu kompromisów klient zdecydował się na AWS ProServe MLDT do produkcji modelu jednoetapowego.

Dopracowując jeden model z większą liczbą oznaczonych danych, AWS ProServe MLDT był w stanie dostarczyć rozwiązanie, które spełniło wymagania klienta dotyczące dokładności modelu, a także spełniło wymagania dotyczące łatwości konserwacji przy jednoczesnym obniżeniu kosztów i zwiększeniu niezawodności.

Wnioski

Duży klient gier szukał sposobu na wykrycie toksycznego języka w swoich kanałach komunikacji, aby promować społecznie odpowiedzialne środowisko gier. AWS GAIIC stworzył PoC detektora toksycznego języka, dostosowując LLM do wykrywania toksycznego języka. AWS ProServe MLDT zaktualizował następnie model szkolenia z podejścia dwuetapowego do podejścia jednoetapowego i wyprodukował LLM dla klienta do wykorzystania na dużą skalę.

W tym poście AWS demonstruje skuteczność i praktyczność precyzyjnego dostrajania LLM w celu rozwiązania tego przypadku użycia klienta, dzieli się kontekstem historii modeli podstawowych i LLM oraz przedstawia przepływ pracy między AWS Generative AI Innovation Center a AWS ProServe ML Zespół dostawy. W następnym poście z tej serii zagłębimy się w sposób, w jaki AWS ProServe MLDT wyprodukował wynikowy jednoetapowy model przy użyciu SageMaker.

Jeśli jesteś zainteresowany współpracą z AWS w celu zbudowania rozwiązania Generative AI, skontaktuj się z nami GAIIC. Ocenią Twój przypadek użycia, opracują dowód koncepcji oparty na sztucznej inteligencji i będą mieli opcje rozszerzenia współpracy z AWS w celu wdrożenia powstałego PoC do produkcji.

Referencje

1. Dane demograficzne graczy: fakty i statystyki dotyczące najpopularniejszego hobby na świecie
2. ChatGPT ustanawia rekord najszybciej rosnącej bazy użytkowników – uwaga analityka
3. Vaswani i wsp., „Uwaga to wszystko, czego potrzebujesz”
4. Radford i in., „Poprawa rozumienia języka przez generatywne szkolenie wstępne”
5. Devlin i wsp., „BERT: wstępne szkolenie głębokich dwukierunkowych transformatorów do rozumienia języka”
6. Yinhan Liu i wsp., „RoBERTa: Solidnie zoptymalizowane podejście do treningu przedtreningowego BERT”
7. Marcos Zampieri i in., „SemEval-2019 Zadanie 6: Identyfikacja i kategoryzacja obraźliwego języka w mediach społecznościowych (OffensEval)”
8. Valerio Basile i in., „SemEval-2019 Zadanie 5: Wielojęzyczne wykrywanie mowy nienawiści wobec imigrantów i kobiet na Twitterze”

O autorach

Jamesa Poquiza jest analitykiem danych w AWS Professional Services z siedzibą w hrabstwie Orange w Kalifornii. Uzyskał tytuł licencjata w dziedzinie informatyki na Uniwersytecie Kalifornijskim w Irvine i ma kilkuletnie doświadczenie w pracy w dziedzinie danych, pełniąc wiele różnych ról. Dziś pracuje nad wdrażaniem i wdrażaniem skalowalnych rozwiązań ML w celu osiągania wyników biznesowych dla klientów AWS.

Han Man jest starszym kierownikiem Data Science & Machine Learning w AWS Professional Services z siedzibą w San Diego w Kalifornii. Posiada tytuł doktora inżynierii uzyskany na Northwestern University i kilkuletnie doświadczenie jako konsultant ds. zarządzania, doradzający klientom w zakresie produkcji, usług finansowych i energii. Obecnie z pasją współpracuje z kluczowymi klientami z różnych branż, aby opracowywać i wdrażać rozwiązania ML i GenAI w AWS.

Safa Tinaztepe jest pełnoetatowym analitykiem danych w AWS Professional Services. Ma licencjat z informatyki z Emory University i interesuje się MLOps, systemami rozproszonymi i web3.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Motoryzacja / pojazdy elektryczne, Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Przesunięcia bloków. Modernizacja własności offsetu środowiskowego. Dostęp tutaj.
• Źródło: 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/