AWS は、大規模言語モデル (LLM) で微調整を実行して、大手ゲーム会社向けに有害な音声を分類します。 アマゾン ウェブ サービス

ビデオ ゲーム業界のユーザー ベースは世界中で 3 億人を超えると推定されています¹。 それは、毎日仮想的に互いに対話する膨大な数のプレイヤーで構成されています。 残念ながら、現実世界と同様に、すべてのプレイヤーが適切かつ敬意を持ってコミュニケーションをとれるわけではありません。 社会的に責任のあるゲーム環境を構築および維持する取り組みの一環として、AWS プロフェッショナル サービスは、オンラインゲームプレイヤーのやり取り内で不適切な言葉 (有害なスピーチ) を検出するメカニズムを構築するよう依頼されました。 全体的なビジネス成果は、既存の手動プロセスを自動化することで組織の運営を改善し、プレイヤー間の不適切なやり取りを検出する速度と品質を向上させることでユーザー エクスペリエンスを向上させ、最終的にはよりクリーンで健全なゲーム環境を促進することでした。

お客様からの要望は、音声とテキストの抜粋を独自のカスタム定義の有害言語カテゴリに分類する英語検出器を作成することでした。 彼らは、まず特定の言語の抜粋が有害かどうかを判断し、次にその抜粋を、冒とく的な言葉や暴言など、顧客が定義した特定の有害なカテゴリに分類したいと考えていました。

AWS ProServe は、Generative AI Innovation Center (GAIIC) と ProServe ML Delivery Team (MLDT) の共同作業を通じて、このユースケースを解決しました。 AWS GAIIC は、顧客と専門家を組み合わせて、概念実証 (PoC) ビルドを使用して幅広いビジネスユースケース向けの生成 AI ソリューションを開発する AWS ProServe 内のグループです。 次に、AWS ProServe MLDT は、顧客向けにソリューションをスケーリング、強化、統合することにより、本番環境を通じて PoC を実行します。

このお客様の使用例は、1 つの別々の投稿で紹介されます。 この投稿 (パート 2) では、科学的方法論を詳しく説明します。 モデルのトレーニングと開発プロセスを含む、ソリューションの背後にある思考プロセスと実験について説明します。 パート XNUMX では、運用化されたソリューションについて詳しく説明し、設計上の決定、データ フロー、モデルのトレーニングと展開アーキテクチャの図を説明します。

この投稿では次のトピックについて説明します。

• このユースケースで AWS ProServe が解決しなければならなかった課題
• 大規模言語モデル (LLM) に関する歴史的背景と、このテクノロジーがこのユースケースに最適である理由
• データサイエンスと機械学習 (ML) の観点から見た AWS GAIIC の PoC と AWS ProServe MLDT のソリューション

データチャレンジ

AWS ProServe が有害な言語分類器のトレーニングで直面した主な課題は、正確なモデルを最初からトレーニングするために十分なラベル付きデータを顧客から取得することでした。 AWS は顧客からラベル付きデータの約 100 サンプルを受け取りましたが、これはデータサイエンスコミュニティで LLM を微調整するために推奨される 1,000 サンプルよりもはるかに少ないです。

追加の固有の課題として、自然言語処理 (NLP) 分類器はトレーニングに非常にコストがかかり、語彙として知られる大量の語彙セットが必要であることが歴史的に知られています。 コー​​パス、正確な予測を生成します。 厳密で効果的な NLP ソリューションは、十分な量のラベル付きデータが提供されている場合、顧客のラベル付きデータを使用してカスタム言語モデルをトレーニングすることになります。 モデルはプレーヤーのゲーム語彙のみを使用してトレーニングされ、ゲーム内で観察される言語に合わせて調整されます。 お客様にはコストと時間の両方の制約があり、このソリューションは実現不可能でした。 AWS ProServe は、比較的小さなラベル付きデータセットを使用して正確な言語毒性分類器をトレーニングするソリューションを見つけることを余儀なくされました。 解決策は、いわゆる 転移学習.

転移学習の背後にある考え方は、事前トレーニングされたモデルの知識を使用し、それを別の比較的類似した問題に適用することです。 たとえば、画像に猫が含まれているかどうかを予測するように画像分類器がトレーニングされている場合、トレーニング中にモデルが得た知識を使用して、トラなどの他の動物を認識できます。 この言語のユースケースでは、AWS ProServe は、有害な言語を検出し、顧客のラベル付きデータを使用して微調整するようにトレーニングされた、以前にトレーニングされた言語分類子を見つける必要がありました。

解決策は、有害な言語を分類するための LLM を見つけて微調整することでした。 LLM は、ラベルのないデータを使用し、通常は数十億の膨大な数のパラメーターを使用してトレーニングされたニューラル ネットワークです。 AWS ソリューションに入る前に、次のセクションでは LLM の歴史とその過去のユースケースについて概要を説明します。

LLM の力を活用する

ChatGPT が史上最も急速に成長している消費者向けアプリケーションとして一般のマインドシェアを獲得して以来、LLM は最近、ML の新しいアプリケーションを探している企業の中心となっています。²、リリースからわずか 100 か月後の 2023 年 2 月までにアクティブ ユーザー数が XNUMX 億人に達します。 ただし、LLM は ML 分野では新しいテクノロジーではありません。 これらは、感情の分析、コーパスの要約、キーワードの抽出、音声の翻訳、テキストの分類などの NLP タスクを実行するために広く使用されています。

テキストの逐次的な性質により、リカレント ニューラル ネットワーク (RNN) が NLP モデリングの最先端技術でした。 具体的には、 エンコーダー-デコーダー ネットワーク アーキテクチャは、任意の長さの入力を受け取り、任意の長さの出力を生成できる RNN 構造を作成したために定式化されました。 これは、通常、入力と出力で単語数が異なる場合に、ある言語の出力フレーズを別の言語の入力フレーズから予測できる翻訳などの NLP タスクに最適でした。 トランスフォーマーのアーキテクチャ³ (Vaswani、2017) は、エンコーダー/デコーダーに関する画期的な改良でした。 という概念を導入しました 自己注意これにより、モデルは入力フレーズと出力フレーズの異なる単語に注意を集中できるようになりました。 一般的なエンコーダ/デコーダでは、各単語はモデルによって同じ方法で解釈されます。 モデルは入力フレーズ内の各単語を順番に処理するため、フレーズの終わりまでに先頭の意味情報が失われる可能性があります。 セルフ アテンション メカニズムは、エンコーダ ブロックとデコーダ ブロックの両方にアテンション レイヤーを追加することでこれを変更しました。これにより、モデルは、出力フレーズで特定の単語を生成するときに、入力フレーズの特定の単語に異なる重み付けを設定できるようになります。 こうしてトランスモデルの基礎が誕生しました。

トランスフォーマー アーキテクチャは、現在使用されている XNUMX つの最もよく知られ人気のある LLM、Bidirectional Encoder Representations from Transformers (BERT) の基礎となりました。⁴ (Radford、2018) と生成事前訓練トランスフォーマー (GPT)⁵ (デブリン 2018)。 GPT モデルの新しいバージョン、つまり GPT3 と GPT4 は、ChatGPT アプリケーションを駆動するエンジンです。 LLM を非常に強力にするレシピの最後の部分は、ULMFiT と呼ばれるプロセスを介して、大規模なラベル付けや前処理を行わずに、膨大なテキスト コーパスから情報を抽出できる機能です。 この方法には、一般的なテキストを収集し、前の単語に基づいて次の単語を予測するタスクでモデルをトレーニングできる事前トレーニング フェーズがあります。 ここでの利点は、トレーニングに使用される入力テキストには、テキストの順序に基づいて本質的に事前にラベルが付けられることです。 LLM は、インターネット規模のデータから学習することができます。 たとえば、元の BERT モデルは BookCorpus と英語版 Wikipedia テキスト データセット全体で事前トレーニングされました。

この新しいモデリング パラダイムは、基盤モデル (FM) と生成 AI という XNUMX つの新しい概念を生み出しました。 従来の教師あり学習の一般的なケースである、タスク固有のデータを使用してモデルを最初からトレーニングするのとは対照的に、LLM は、特定のタスクやドメインに適用される前に、広範囲のテキスト データセットから一般的な知識を抽出するように事前トレーニングされます。データセット (通常は数百のサンプル程度)。 新しい ML ワークフローは、基礎モデルと呼ばれる事前トレーニングされたモデルから始まります。 適切な基盤の上に構築することが重要であり、新しいオプションなどの選択肢が増えています。 Amazon Titan FMの一部として AWS によってリリースされる予定です。 アマゾンの岩盤。 これらの新しいモデルは、その出力が人間によって解釈可能であり、入力データと同じデータ型であるため、生成的であるとも考えられます。 過去の ML モデルは猫と犬の画像を分類するなど記述的でしたが、LLM の出力は入力単語に基づいた次の単語セットであるため、生成的です。 これにより、生成するコンテンツで表現力豊かな ChatGPT などの対話型アプリケーションを強化できるようになります。

HuggingFaceはAWSと提携しています FM を民主化し、簡単にアクセスして構築できるようにします。 ハグフェイスは トランスフォーマー API 異なる ML フレームワーク上の 50 を超える異なるトランスフォーマー アーキテクチャを統合し、事前トレーニングされたモデルの重みへのアクセスを含みます。 モデルハブ、この記事を書いている時点で 200,000 モデルを超えています。 次のセクションでは、概念実証、ソリューション、および顧客向けの有害な音声分類のユースケースを解決するための基礎としてテストされ選択された FM について説明します。

AWS GAIIC の概念実証

AWS GAIIC は、有害な言語分類子を微調整するために、BERT アーキテクチャを備えた LLM 基盤モデルを実験することを選択しました。 Hugging Face のモデル ハブの合計 XNUMX つのモデルがテストされました。

XNUMX つのモデル アーキテクチャはすべて、 ベルトツイート 建築。 BERTweet は、以下に基づいてトレーニングされます。 ロベルタ トレーニング前の手順。 RoBERTa 事前トレーニング手順は、BERT モデルのトレーニングのレシピを改善するためにハイパーパラメーター調整とトレーニング セット サイズの効果を評価した BERT 事前トレーニングの再現研究の結果です。⁶ (Liu 2019)。 実験では、基礎となるアーキテクチャを変更せずに BERT のパフォーマンス結果を改善する事前トレーニング方法を見つけることを目指しました。 研究の結論として、次のトレーニング前の変更により BERT のパフォーマンスが大幅に向上することがわかりました。

• より多くのデータを使用してより大きなバッチを使用してモデルをトレーニングする
• 次の文の予測目標を削除する
• より長いシーケンスのトレーニング
• トレーニングデータに適用されるマスキングパターンを動的に変更する

bertweet ベースのモデルは、RoBERTa 研究からの事前トレーニング手順を使用して、850 億 XNUMX 万の英語ツイートを使用して元の BERT アーキテクチャを事前トレーニングします。 これは、英語のツイート用に事前トレーニングされた初の公開された大規模言語モデルです。

ツイートを使用して事前トレーニングされた FM は、次の XNUMX つの主な理論的理由からユースケースに適合すると考えられました。

• ツイートの長さは、オンライン ゲーム チャットで見られる不適切または有害なフレーズの長さと非常に似ています。
• ツイートは、ゲーム プラットフォームで見られる人口と同様の、多種多様なユーザーからなる集団から発信されます。

AWS は、まず顧客のラベル付きデータを使用して BERTweet を微調整してベースラインを取得することにしました。 次に、他の 14,100 つの FM を、より関連性の高い有害なツイートに特化してさらに事前トレーニングし、潜在的により高い精度を達成するために、ツイートベースの攻撃とツイートベースの嫌悪に関して微調整することを選択しました。 bertweet-base-offensive モデルは、ベースの BertTweet FM を使用し、攻撃的であるとみなされた XNUMX 件の注釈付きツイートでさらに事前トレーニングされています。⁷ （ザンピエリ2019）。 bertweet-base-hate モデルも基本 BertTweet FM を使用しますが、ヘイトスピーチとみなされた 19,600 件のツイートでさらに事前トレーニングされています。⁸ (Basile 2019)。

PoC モデルのパフォーマンスをさらに強化するために、AWS GAIIC は XNUMX つの設計上の決定を行いました。

• XNUMX 段階の予測フローを作成しました。最初のモデルは、テキストの一部が有害か無害かを分類するバイナリ分類子として機能します。 XNUMX 番目のモデルは、顧客が定義した有害なタイプに基づいてテキストを分類するきめの細かいモデルです。 最初のモデルがテキストを有害であると予測した場合にのみ、そのテキストは XNUMX 番目のモデルに渡されます。
• トレーニング データを拡張し、公開された Kaggle コンペティション (ジグソーの毒性) を顧客から受け取った元の 100 個のサンプルに追加します。 彼らはジグソー ラベルを関連する顧客定義の毒性ラベルにマッピングし、80% をトレーニング データとして分割し、20% をテスト データとして分割してモデルを検証しました。

AWS GAIICを使用 アマゾンセージメーカー ノートブックを使用して微調整実験を実行したところ、bertweet-base-offensive モデルが検証セットで最高のスコアを達成したことがわかりました。 次の表は、観察されたメトリック スコアをまとめたものです。

この時点から、GAIIC は PoC を AWS ProServe ML 配信チームに引き渡し、PoC を本番化しました。

AWS ProServe ML デリバリーチームソリューション

モデル アーキテクチャを実稼働化するために、AWS ProServe ML Delivery Team (MLDT) はお客様から、スケーラブルで保守が容易なソリューションを作成するよう依頼されました。 XNUMX 段階モデル​​のアプローチには、メンテナンスに関するいくつかの課題がありました。

• モデルでは XNUMX 倍の量のモデル モニタリングが必要になるため、再トレーニングのタイミングが不安定になります。 一方のモデルを他方のモデルよりも頻繁に再トレーニングする必要がある場合があります。
• XNUMX つのモデルではなく XNUMX つのモデルを実行するとコストが増加します。
• 推論はXNUMXつのモデルを経由するため推論速度が遅くなります。

これらの課題に対処するために、AWS ProServe MLDT は、XNUMX ステージ アーキテクチャの精度を維持しながら、XNUMX ステージ モデル アーキテクチャを単一モデル アーキテクチャに変換する方法を見つけ出す必要がありました。

解決策は、まず顧客にさらにトレーニング データを要求し、次に無毒サンプルを含むすべてのラベルのベルトツイートベース攻撃モデルを XNUMX つのモデルに微調整することでした。 より多くのデータを使用して XNUMX つのモデルを微調整すると、より少ないデータで XNUMX 段階のモデル アーキテクチャを微調整した場合と同様の結果が得られるという考えでした。 XNUMX 段階のモデル アーキテクチャを微調整するために、AWS ProServe MLDT は、事前トレーニングされたモデルのマルチラベル分類ヘッドを更新して、無害なクラスを表す追加のノードを XNUMX つ含めました。

以下は、トランスフォーマー プラットフォームを使用して Hugging Face モデル ハブの事前トレーニング済みモデルを微調整し、モデルのマルチラベル分類ヘッドを変更して必要なクラス数を予測する方法を示すコード サンプルです。 AWS ProServe MLDT は、このブループリントを微調整の基礎として使用しました。 トレーニング データと検証データが準備されており、正しい入力形式であることを前提としています。

まず、Python モジュールと必要な事前トレーニング済みモデルが 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)

その後、事前トレーニングされたモデルがロードされ、微調整の準備が整います。 これは、有害なカテゴリの数とすべてのモデル パラメーターを定義するステップです。

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

モデルの微調整は、トレーニング データセットと検証データセットへのパスを入力することから始まります。

# 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 は、さらに約 5,000 個のラベル付きデータサンプル (3,000 個は無毒、2,000 個は有毒) を受け取り、5,000 つのツイートベースのモデルすべてを微調整して、すべてのラベルを 80 つのモデルに結合しました。 彼らは、PoC からの 20 サンプルに加えてこのデータを使用し、同じ XNUMX% トレーニング セット、XNUMX% テスト セット手法を使用して新しい XNUMX 段階モデル​​を微調整しました。 次の表は、パフォーマンス スコアが XNUMX 段階モデル​​のパフォーマンス スコアと同等であることを示しています。

3 段階モデル​​のアプローチにより、精度が XNUMX% 低下するだけでコストとメンテナンスが改善されました。 トレードオフを比較検討した結果、お客様は XNUMX 段階モデル​​を実稼働化するために AWS ProServe MLDT を選択しました。

AWS ProServe MLDT は、より多くのラベル付きデータを使用して XNUMX つのモデルを微調整することで、コストを削減し堅牢性を向上させながら、モデルの精度に関する顧客のしきい値を満たすソリューションを提供できるだけでなく、メンテナンスの容易さに対する顧客の要望にも応えることができました。

まとめ

ある大規模なゲーム顧客は、社会的責任のあるゲーム環境を促進するために、コミュニケーション チャネル内の有害な言語を検出する方法を探していました。 AWS GAIIC は、有害な言語を検出するために LLM を微調整することにより、有害な言語検出器の PoC を作成しました。 その後、AWS ProServe MLDT は、モデルのトレーニング フローを XNUMX 段階のアプローチから XNUMX 段階のアプローチに更新し、顧客が大規模に使用できるように LLM を実稼働しました。

この投稿では、AWS がこの顧客のユースケースを解決するために LLM を微調整する有効性と実用性を実証し、基盤モデルと LLM の歴史に関するコンテキストを共有し、AWS Generative AI Innovation Center と AWS ProServe ML の間のワークフローを紹介します。配達チーム。 このシリーズの次の投稿では、AWS ProServe MLDT が SageMaker を使用して結果として得られた XNUMX ステージ モデルをどのように本番化したかについて詳しく説明します。

AWS と協力して Generative AI ソリューションを構築することに興味がある場合は、 ガイック。 彼らは、お客様のユースケースを評価し、Generative-AI ベースの概念実証を構築し、AWS とのコラボレーションを拡張して結果として得られる PoC を本番環境に実装するオプションを備えています。

参考文献

1. ゲーマー人口統計: 世界で最も人気のある趣味に関する事実と統計
2. ChatGPT がユーザーベースの急成長記録を樹立 – アナリストのメモ
3. バスワニ他、「必要なのは注意だけです」
4. Radford et al.、「生成的事前トレーニングによる言語理解の改善」
5. Devlin et al.、「BERT: 言語理解のための深い双方向トランスフォーマーの事前トレーニング」
6. yinghan liu 他、「RoBERTa: 堅牢に最適化された BERT 事前トレーニング アプローチ」
7. Marcos Zampieri 他、「SemEval-2019 タスク 6: ソーシャル メディアにおける攻撃的な言語の特定と分類 (OffensEval)」
8. Valerio Basile 他、「SemEval-2019 タスク 5: Twitter における移民および女性に対するヘイトスピーチの多言語検出」

著者について

ジェームズ・ポキス は、カリフォルニア州オレンジ郡を拠点とする AWS プロフェッショナル サービスのデータ サイエンティストです。 彼は、カリフォルニア大学アーバイン校でコンピュータ サイエンスの学士号を取得しており、データ ドメインで数年間、さまざまな役割を果たしてきました。 現在、彼はスケーラブルな ML ソリューションの実装とデプロイに取り組んでおり、AWS クライアントのビジネス成果を達成しています。

ハンマン は、カリフォルニア州サンディエゴを拠点とする AWS プロフェッショナル サービスのシニア データ サイエンス & 機械学習マネージャーです。 彼はノースウェスタン大学で工学博士号を取得しており、製造、金融サービス、エネルギー分野のクライアントにアドバイスする経営コンサルタントとして数年の経験があります。 現在、彼はさまざまな業界の主要顧客と熱心に協力して、AWS 上で ML および GenAI ソリューションを開発および実装しています。

サファ・ティナステペ は、AW​​S プロフェッショナル サービスのフルスタック データ サイエンティストです。 彼はエモリー大学でコンピューター サイエンスの学士号を取得しており、MLOps、分散システム、および Web3 に興味を持っています。

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 自動車/EV、 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• ブロックオフセット。 環境オフセット所有権の近代化。 こちらからアクセスしてください。
• 情報源： 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/