AWS führt für ein großes Gaming-Unternehmen eine Feinabstimmung an einem Large Language Model (LLM) durch, um toxische Sprache zu klassifizieren | Amazon Web Services

Die Videospielbranche hat weltweit eine geschätzte Nutzerbasis von über 3 Milliarden¹. Es besteht aus riesigen Mengen an Spielern, die jeden Tag virtuell miteinander interagieren. Leider kommunizieren, wie auch in der realen Welt, nicht alle Spieler angemessen und respektvoll. Um eine sozial verantwortliche Spielumgebung zu schaffen und aufrechtzuerhalten, wurde AWS Professional Services gebeten, einen Mechanismus zu entwickeln, der unangemessene Sprache (toxische Sprache) bei Interaktionen von Online-Gaming-Spielern erkennt. Das allgemeine Geschäftsergebnis bestand darin, die Betriebsabläufe der Organisation durch die Automatisierung eines bestehenden manuellen Prozesses zu verbessern und das Benutzererlebnis durch eine höhere Geschwindigkeit und Qualität bei der Erkennung unangemessener Interaktionen zwischen Spielern zu verbessern und so letztendlich eine sauberere und gesündere Spielumgebung zu fördern.

Die Aufgabe des Kunden bestand darin, einen Detektor für die englische Sprache zu entwickeln, der Sprach- und Textauszüge in ihre eigenen, benutzerdefinierten toxischen Sprachkategorien einordnet. Sie wollten zunächst feststellen, ob der gegebene Sprachauszug toxisch ist, und ihn dann in eine bestimmte, vom Kunden definierte Toxizitätskategorie wie Obszönität oder beleidigende Sprache einordnen.

AWS ProServe hat diesen Anwendungsfall durch eine gemeinsame Anstrengung des Generative AI Innovation Center (GAIIC) und des ProServe ML Delivery Team (MLDT) gelöst. Das AWS GAIIC ist eine Gruppe innerhalb von AWS ProServe, die Kunden mit Experten zusammenbringt, um mithilfe von Proof-of-Concept-Builds (PoC) generative KI-Lösungen für eine Vielzahl von Geschäftsanwendungsfällen zu entwickeln. Anschließend führt AWS ProServe MLDT den PoC durch die Produktion, indem es die Lösung für den Kunden skaliert, härtet und integriert.

Dieser Kundenanwendungsfall wird in zwei separaten Beiträgen vorgestellt. Dieser Beitrag (Teil 1) dient als tiefer Einblick in die wissenschaftliche Methodik. Es wird der Denkprozess und das Experimentieren hinter der Lösung erläutert, einschließlich des Modellschulungs- und Entwicklungsprozesses. Teil 2 befasst sich mit der produzierten Lösung, erläutert die Entwurfsentscheidungen, den Datenfluss und veranschaulicht die Modelltrainings- und Bereitstellungsarchitektur.

Dieser Beitrag behandelt die folgenden Themen:

• Die Herausforderungen, die AWS ProServe für diesen Anwendungsfall lösen musste
• Historischer Kontext zu großen Sprachmodellen (LLMs) und warum diese Technologie perfekt für diesen Anwendungsfall geeignet ist
• Der PoC von AWS GAIIC und die Lösung von AWS ProServe MLDT aus Sicht der Datenwissenschaft und des maschinellen Lernens (ML).

Datenherausforderung

Die größte Herausforderung für AWS ProServe beim Training eines toxischen Sprachklassifikators bestand darin, vom Kunden genügend gekennzeichnete Daten zu erhalten, um ein genaues Modell von Grund auf zu trainieren. AWS hat vom Kunden etwa 100 Proben gekennzeichneter Daten erhalten, was deutlich weniger ist als die 1,000 Proben, die für die Feinabstimmung eines LLM in der Data-Science-Community empfohlen werden.

Als zusätzliche inhärente Herausforderung gilt, dass Klassifikatoren für die Verarbeitung natürlicher Sprache (Natural Language Processing, NLP) in der Vergangenheit bekanntermaßen sehr kostspielig zu trainieren sind und einen großen Satz Vokabular erfordern, der als a bezeichnet wird Korpus, um genaue Vorhersagen zu erstellen. Eine rigorose und effektive NLP-Lösung bestünde bei Bereitstellung ausreichender Mengen an gekennzeichneten Daten darin, ein benutzerdefiniertes Sprachmodell unter Verwendung der gekennzeichneten Daten des Kunden zu trainieren. Das Modell würde ausschließlich mit dem Spielvokabular der Spieler trainiert und so auf die in den Spielen beobachtete Sprache zugeschnitten. Der Kunde hatte sowohl Kosten- als auch Zeitbeschränkungen, die diese Lösung unrentabel machten. AWS ProServe war gezwungen, eine Lösung zu finden, um einen genauen Sprachtoxizitätsklassifizierer mit einem relativ kleinen beschrifteten Datensatz zu trainieren. Die Lösung lag in dem sogenannten Transferlernen.

Die Idee hinter Transferlernen besteht darin, das Wissen eines vorab trainierten Modells zu nutzen und es auf ein anderes, aber relativ ähnliches Problem anzuwenden. Wenn beispielsweise ein Bildklassifikator darauf trainiert wurde, vorherzusagen, ob ein Bild eine Katze enthält, könnten Sie das Wissen, das das Modell während seines Trainings gewonnen hat, nutzen, um andere Tiere wie Tiger zu erkennen. Für diesen Sprachanwendungsfall musste AWS ProServe einen zuvor trainierten Sprachklassifikator finden, der darauf trainiert war, toxische Sprache zu erkennen und sie anhand der gekennzeichneten Daten des Kunden zu optimieren.

Die Lösung bestand darin, ein LLM zu finden und zu optimieren, um toxische Sprache zu klassifizieren. LLMs sind neuronale Netze, die mithilfe einer riesigen Anzahl von Parametern, typischerweise in der Größenordnung von Milliarden, und unter Verwendung unbeschrifteter Daten trainiert wurden. Bevor auf die AWS-Lösung eingegangen wird, bietet der folgende Abschnitt einen Überblick über die Geschichte von LLMs und ihre historischen Anwendungsfälle.

Die Kraft von LLMs nutzen

LLMs sind in letzter Zeit zum Brennpunkt für Unternehmen geworden, die nach neuen ML-Anwendungen suchen, seit ChatGPT als am schnellsten wachsende Verbraucheranwendung in der Geschichte die Aufmerksamkeit der Öffentlichkeit auf sich gezogen hat²und erreichte im Januar 100, nur zwei Monate nach seiner Veröffentlichung, 2023 Millionen aktive Nutzer. Allerdings sind LLMs keine neue Technologie im ML-Bereich. Sie wurden ausgiebig zur Durchführung von NLP-Aufgaben wie der Analyse von Stimmungen, der Zusammenfassung von Korpussen, der Extraktion von Schlüsselwörtern, der Übersetzung von Sprache und der Klassifizierung von Texten eingesetzt.

Aufgrund der sequentiellen Natur von Text waren rekurrente neuronale Netze (RNNs) der Stand der Technik für die NLP-Modellierung. Konkret die Encoder-Decoder Die Netzwerkarchitektur wurde formuliert, weil sie eine RNN-Struktur schuf, die in der Lage ist, eine Eingabe beliebiger Länge anzunehmen und eine Ausgabe beliebiger Länge zu erzeugen. Dies war ideal für NLP-Aufgaben wie Übersetzungen, bei denen eine Ausgabephrase einer Sprache aus einer Eingabephrase einer anderen Sprache vorhergesagt werden konnte, typischerweise mit einer unterschiedlichen Anzahl von Wörtern zwischen Eingabe und Ausgabe. Die Transformer-Architektur³ (Vaswani, 2017) war eine bahnbrechende Verbesserung gegenüber dem Encoder-Decoder; es führte das Konzept von ein SelbstaufmerksamkeitDadurch konnte das Modell seine Aufmerksamkeit auf verschiedene Wörter in den Eingabe- und Ausgabephrasen richten. In einem typischen Encoder-Decoder wird jedes Wort vom Modell auf identische Weise interpretiert. Da das Modell jedes Wort in einer Eingabephrase nacheinander verarbeitet, können die semantischen Informationen am Anfang am Ende der Phrase verloren gehen. Der Selbstaufmerksamkeitsmechanismus änderte dies, indem er sowohl dem Encoder- als auch dem Decoderblock eine Aufmerksamkeitsschicht hinzufügte, sodass das Modell bestimmte Wörter aus der Eingabephrase unterschiedlich gewichten konnte, wenn ein bestimmtes Wort in der Ausgabephrase generiert wurde. Damit war die Grundlage des Transformatormodells geboren.

Die Transformatorarchitektur war die Grundlage für zwei der bekanntesten und beliebtesten LLMs, die heute verwendet werden: die Bidirektionalen Encoderdarstellungen von Transformers (BERT).⁴ (Radford, 2018) und der Generative Pretrained Transformer (GPT)⁵ (Devlin 2018). Spätere Versionen des GPT-Modells, nämlich GPT3 und GPT4, sind die Engine, die die ChatGPT-Anwendung antreibt. Der letzte Teil des Rezepts, das LLMs so leistungsfähig macht, ist die Fähigkeit, Informationen aus riesigen Textkorpussen ohne umfangreiche Kennzeichnung oder Vorverarbeitung über einen Prozess namens ULMFiT zu destillieren. Diese Methode verfügt über eine Vortrainingsphase, in der allgemeiner Text gesammelt werden kann und das Modell auf die Aufgabe trainiert wird, das nächste Wort basierend auf vorherigen Wörtern vorherzusagen; Der Vorteil besteht darin, dass jeder Eingabetext, der für das Training verwendet wird, automatisch entsprechend der Reihenfolge des Textes vorbeschriftet ist. LLMs sind wirklich in der Lage, aus Daten im Internetmaßstab zu lernen. Beispielsweise wurde das ursprüngliche BERT-Modell auf dem BookCorpus und gesamten englischen Wikipedia-Textdatensätzen vorab trainiert.

Dieses neue Modellierungsparadigma hat zu zwei neuen Konzepten geführt: Grundlagenmodelle (FMs) und generative KI. Im Gegensatz zum Training eines Modells von Grund auf mit aufgabenspezifischen Daten, was beim klassischen überwachten Lernen üblich ist, werden LLMs vorab trainiert, um allgemeines Wissen aus einem breiten Textdatensatz zu extrahieren, bevor sie mit einem viel kleineren Maß an spezifische Aufgaben oder Domänen angepasst werden Datensatz (normalerweise in der Größenordnung von Hunderten von Proben). Der neue ML-Workflow beginnt nun mit einem vorab trainierten Modell, das als Basismodell bezeichnet wird. Es ist wichtig, auf dem richtigen Fundament aufzubauen, und es gibt immer mehr Optionen, wie zum Beispiel das Neue Amazon Titan FMs, wird von AWS als Teil von veröffentlicht Amazonas Grundgestein. Diese neuen Modelle gelten auch als generativ, da ihre Ausgaben vom Menschen interpretierbar sind und denselben Datentyp wie die Eingabedaten haben. Während frühere ML-Modelle deskriptiv waren und beispielsweise Bilder von Katzen vs. Hunden klassifizierten, sind LLMs generativ, da ihre Ausgabe der nächste Satz von Wörtern ist, die auf Eingabewörtern basieren. Dadurch können sie interaktive Anwendungen wie ChatGPT betreiben, die in den von ihnen generierten Inhalten ausdrucksstark sein können.

Hugging Face ist eine Partnerschaft mit AWS eingegangen um FMs zu demokratisieren und den Zugang und die Zusammenarbeit mit ihnen zu erleichtern. Hugging Face hat ein erstellt Transformers-API das mehr als 50 verschiedene Transformatorarchitekturen auf verschiedenen ML-Frameworks vereint, einschließlich des Zugriffs auf vorab trainierte Modellgewichte darin Modell Hub, die zum Zeitpunkt des Schreibens dieses Beitrags auf über 200,000 Modelle angewachsen ist. In den nächsten Abschnitten untersuchen wir den Proof of Concept, die Lösung und die FMs, die getestet und als Grundlage für die Lösung dieses Anwendungsfalls der toxischen Sprachklassifizierung für den Kunden ausgewählt wurden.

AWS GAIIC Proof of Concept

AWS GAIIC entschied sich für das Experimentieren mit LLM-Grundlagenmodellen mit der BERT-Architektur, um einen toxischen Sprachklassifikator zu optimieren. Insgesamt wurden drei Modelle aus dem Modellhub von Hugging Face getestet:

Alle drei Modellarchitekturen basieren auf dem BERTweet die Architektur. BERTweet basiert auf dem Training Roberta Verfahren vor dem Training. Das RoBERTa-Vortrainingsverfahren ist das Ergebnis einer Replikationsstudie des BERT-Vortrainings, in der die Auswirkungen der Hyperparameter-Abstimmung und der Trainingssatzgröße bewertet wurden, um das Rezept für das Training von BERT-Modellen zu verbessern⁶ (Liu 2019). Ziel des Experiments war es, eine Pre-Training-Methode zu finden, die die Leistungsergebnisse von BERT verbessert, ohne die zugrunde liegende Architektur zu ändern. Die Schlussfolgerung der Studie ergab, dass die folgenden Modifikationen vor dem Training die Leistung von BERT erheblich verbesserten:

• Trainieren Sie das Modell mit größeren Batches und mehr Daten
• Entfernen des Vorhersageziels für den nächsten Satz
• Training an längeren Sequenzen
• Dynamisches Ändern des auf die Trainingsdaten angewendeten Maskierungsmusters

Das Bertweet-Basismodell nutzt das vorhergehende Vortrainingsverfahren aus der RoBERTa-Studie, um die ursprüngliche BERT-Architektur anhand von 850 Millionen englischen Tweets vorab zu trainieren. Es ist das erste öffentliche, groß angelegte Sprachmodell, das für englische Tweets vorab trainiert wurde.

Es wurde angenommen, dass vorab trainierte FMs, die Tweets verwenden, aus zwei theoretischen Hauptgründen für den Anwendungsfall geeignet sind:

• Die Länge eines Tweets ist der Länge einer unangemessenen oder giftigen Phrase in Online-Spielchats sehr ähnlich
• Tweets stammen von einer Bevölkerung mit einer großen Vielfalt unterschiedlicher Nutzer, ähnlich der Bevölkerung auf Spieleplattformen

AWS beschloss, BERTweet zunächst mit den gekennzeichneten Daten des Kunden zu verfeinern, um eine Basislinie zu erhalten. Anschließend entschied man sich für die Feinabstimmung zweier weiterer FMs in bertweet-base-offensive und bertweet-base-hate, die speziell auf relevantere toxische Tweets weiter vorab trainiert wurden, um eine potenziell höhere Genauigkeit zu erreichen. Das Bertweet-Base-Offensive-Modell verwendet die Basis BertTweet FM und wird anhand von 14,100 kommentierten Tweets, die als anstößig eingestuft wurden, weiter vorab trainiert⁷ (Zampieri 2019). Das Bertweet-Base-Hate-Modell verwendet ebenfalls die Basis BertTweet FM, ist jedoch weiter vorab auf 19,600 Tweets trainiert, die als Hassrede eingestuft wurden⁸ (Basile 2019).

Um die Leistung des PoC-Modells weiter zu verbessern, hat AWS GAIIC zwei Designentscheidungen getroffen:

• Es wurde ein zweistufiger Vorhersagefluss erstellt, bei dem das erste Modell als binärer Klassifikator fungiert, der klassifiziert, ob ein Textstück giftig ist oder nicht. Das zweite Modell ist ein feinkörniges Modell, das Text basierend auf den vom Kunden definierten toxischen Typen klassifiziert. Nur wenn das erste Modell den Text als toxisch vorhersagt, wird er an das zweite Modell übergeben.
• Die Trainingsdaten wurden erweitert und eine Teilmenge eines von einem Drittanbieter gekennzeichneten toxischen Textdatensatzes aus einem öffentlichen Kaggle-Wettbewerb hinzugefügt (Jigsaw-Toxizität) auf die ursprünglich vom Kunden erhaltenen 100 Muster. Sie ordneten die Jigsaw-Etiketten den zugehörigen, vom Kunden definierten Toxizitätsetiketten zu und führten eine 80-prozentige Aufteilung als Trainingsdaten und eine 20-prozentige Aufteilung als Testdaten durch, um das Modell zu validieren.

AWS GAIIC verwendet Amazon Sage Maker Notebooks, um ihre Feinabstimmungsexperimente durchzuführen, und stellten fest, dass das Bertweet-Base-Offensive-Modell die besten Ergebnisse im Validierungssatz erzielte. Die folgende Tabelle fasst die beobachteten Metrikwerte zusammen.

Ab diesem Zeitpunkt übergab GAIIC den PoC an das AWS ProServe ML Delivery Team, um den PoC zu erstellen.

AWS ProServe ML Delivery Team-Lösung

Um die Modellarchitektur zu produzieren, wurde das AWS ProServe ML Delivery Team (MLDT) vom Kunden gebeten, eine Lösung zu erstellen, die skalierbar und einfach zu warten ist. Bei einem zweistufigen Modellansatz gab es einige Wartungsherausforderungen:

• Die Modelle würden den doppelten Umfang der Modellüberwachung erfordern, was zu inkonsistenten Umschulungszeiten führt. Es kann vorkommen, dass ein Modell häufiger neu trainiert werden muss als das andere.
• Erhöhte Kosten für den Betrieb von zwei Modellen im Gegensatz zu einem.
• Die Geschwindigkeit der Schlussfolgerung verlangsamt sich, da die Schlussfolgerung zwei Modelle durchläuft.

Um diese Herausforderungen zu bewältigen, musste AWS ProServe MLDT herausfinden, wie die zweistufige Modellarchitektur in eine einzelne Modellarchitektur umgewandelt werden kann und gleichzeitig die Genauigkeit der zweistufigen Architektur erhalten bleibt.

Die Lösung bestand darin, den Kunden zunächst um weitere Trainingsdaten zu bitten und dann das Bertweet-Base-Offensive-Modell auf allen Etiketten, einschließlich ungiftiger Proben, in einem Modell zu verfeinern. Die Idee war, dass die Feinabstimmung eines Modells mit mehr Daten zu ähnlichen Ergebnissen führen würde wie die Feinabstimmung einer zweistufigen Modellarchitektur mit weniger Daten. Zur Feinabstimmung der zweistufigen Modellarchitektur hat AWS ProServe MLDT den vorab trainierten Multi-Label-Klassifizierungskopf des Modells aktualisiert, um einen zusätzlichen Knoten zur Darstellung der ungiftigen Klasse aufzunehmen.

Im Folgenden finden Sie ein Codebeispiel dafür, wie Sie ein vorab trainiertes Modell aus dem Hugging Face-Modell-Hub mithilfe der Transformer-Plattform optimieren und den Multi-Label-Klassifizierungskopf des Modells ändern würden, um die gewünschte Anzahl von Klassen vorherzusagen. AWS ProServe MLDT nutzte diesen Entwurf als Grundlage für die Feinabstimmung. Es wird davon ausgegangen, dass Sie Ihre Zugdaten und Validierungsdaten bereit haben und im richtigen Eingabeformat vorliegen.

Zunächst werden Python-Module sowie das gewünschte vorab trainierte Modell aus dem Hugging Face-Modell-Hub importiert:

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

Das vorab trainierte Modell wird dann geladen und für die Feinabstimmung vorbereitet. In diesem Schritt werden die Anzahl der toxischen Kategorien und alle Modellparameter definiert:

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

Die Feinabstimmung des Modells beginnt mit der Eingabe von Pfaden zu den Trainings- und Validierungsdatensätzen:

# 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 erhielt etwa 5,000 weitere gekennzeichnete Datenproben, von denen 3,000 ungiftig und 2,000 toxisch waren, und optimierte alle drei Bertweet-Basismodelle und kombinierte alle Etiketten in einem Modell. Sie nutzten diese Daten zusätzlich zu den 5,000 Proben aus dem PoC, um neue einstufige Modelle mit derselben Methode aus 80 % Zugsatz und 20 % Testsatz zu verfeinern. Die folgende Tabelle zeigt, dass die Leistungswerte mit denen des zweistufigen Modells vergleichbar waren.

Der einstufige Modellansatz führte zu Kosten- und Wartungsverbesserungen und verringerte gleichzeitig die Präzision nur um 3 %. Nach Abwägung der Kompromisse entschied sich der Kunde für AWS ProServe MLDT zur Produktion des einstufigen Modells.

Durch die Feinabstimmung eines Modells mit mehr gekennzeichneten Daten konnte AWS ProServe MLDT eine Lösung liefern, die den Schwellenwert des Kunden hinsichtlich der Modellgenauigkeit erfüllte und seiner Forderung nach einfacher Wartung nachkam, während gleichzeitig die Kosten gesenkt und die Robustheit erhöht wurden.

Zusammenfassung

Ein großer Gaming-Kunde suchte nach einer Möglichkeit, toxische Sprache in seinen Kommunikationskanälen zu erkennen, um ein sozial verantwortliches Gaming-Umfeld zu fördern. AWS GAIIC hat durch die Feinabstimmung eines LLM zur Erkennung toxischer Sprache einen PoC eines Toxic-Language-Detektors erstellt. Anschließend aktualisierte AWS ProServe MLDT den Modellschulungsablauf von einem zweistufigen Ansatz auf einen einstufigen Ansatz und produzierte das LLM für den Kunden, um es in großem Maßstab zu verwenden.

In diesem Beitrag demonstriert AWS die Effektivität und Praktikabilität der Feinabstimmung eines LLM zur Lösung dieses Kundenanwendungsfalls, teilt Kontext zur Geschichte von Basismodellen und LLMs und stellt den Workflow zwischen dem AWS Generative AI Innovation Center und AWS ProServe ML vor Lieferteam. Im nächsten Beitrag dieser Reihe werden wir tiefer darauf eingehen, wie AWS ProServe MLDT das resultierende einstufige Modell mit SageMaker erstellt hat.

Wenn Sie daran interessiert sind, mit AWS zusammenzuarbeiten, um eine generative KI-Lösung zu entwickeln, wenden Sie sich bitte an die GAIIC. Sie bewerten Ihren Anwendungsfall, erstellen einen Proof of Concept auf Basis generativer KI und haben die Möglichkeit, die Zusammenarbeit mit AWS auszuweiten, um den resultierenden PoC in die Produktion zu implementieren.

Bibliographie

1. Gamer-Demografie: Fakten und Statistiken zum beliebtesten Hobby der Welt
2. ChatGPT stellt Rekord für die am schnellsten wachsende Benutzerbasis auf – Analystenhinweis
3. Vaswani et al., „Aufmerksamkeit ist alles, was Sie brauchen“
4. Radford et al., „Verbesserung des Sprachverständnisses durch generatives Pre-Training“
5. Devlin et al., „BERT: Vorschulung tiefer bidirektionaler Transformatoren zum Sprachverständnis“
6. Yinhan Liu et al., „RoBERTa: Ein robust optimierter BERT-Pretraining-Ansatz“
7. Marcos Zampieri et al., „SemEval-2019 Aufgabe 6: Identifizierung und Kategorisierung beleidigender Sprache in sozialen Medien (OffensEval)“
8. Valerio Basile et al., „SemEval-2019 Aufgabe 5: Mehrsprachige Erkennung von Hassreden gegen Einwanderer und Frauen in Twitter“

Über die Autoren

James Poquiz ist Datenwissenschaftler bei AWS Professional Services mit Sitz in Orange County, Kalifornien. Er hat einen Bachelor-Abschluss in Informatik von der University of California, Irvine und verfügt über mehrere Jahre Erfahrung im Datenbereich, in denen er viele verschiedene Rollen gespielt hat. Heute arbeitet er an der Implementierung und Bereitstellung skalierbarer ML-Lösungen, um Geschäftsergebnisse für AWS-Kunden zu erzielen.

Han-Man ist Senior Data Science & Machine Learning Manager bei AWS Professional Services mit Sitz in San Diego, Kalifornien. Er hat einen Doktortitel in Ingenieurwissenschaften von der Northwestern University und verfügt über mehrere Jahre Erfahrung als Unternehmensberater, der Kunden in den Bereichen Fertigung, Finanzdienstleistungen und Energie berät. Heute arbeitet er leidenschaftlich mit Schlüsselkunden aus verschiedenen Branchen zusammen, um ML- und GenAI-Lösungen auf AWS zu entwickeln und zu implementieren.

Safa Tinaztepe ist ein Full-Stack-Datenwissenschaftler bei AWS Professional Services. Er hat einen Bachelor-Abschluss in Informatik von der Emory University und interessiert sich für MLOps, verteilte Systeme und Web3.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Automobil / Elektrofahrzeuge, Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• BlockOffsets. Modernisierung des Eigentums an Umweltkompensationen. Hier zugreifen.
• Quelle: 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/