re:Invent 2023: Amazon BedrockのFMを活用したテキスト生成ユースケース
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Explore text-generation FMs for top use cases with Amazon Bedrock (AIM333)
この動画では、Amazon Bedrockのテキスト生成基盤モデルの活用方法を探ります。Usmanらが、多様なデータ処理や顧客体験向上、従業員生産性アップなど、具体的なユースケースを紹介します。また、AlidaのDanielが、Amazon BedrockとAnthropicのモデルを使った革新的なテキスト分析エンジンの構築過程を詳しく解説。多言語対応や文脈理解の向上など、実用的な洞察が得られる内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon Bedrockのテキスト生成基盤モデルセッションの紹介
皆様、こんにちは。Amazon Bedrockのテキスト生成基盤モデルを探求するセッションにお越しいただき、ありがとうございます。私はUsman Anwerで、Amazon Bedrockサービスの創設メンバーの一人です。本日は、worldwide sales organizationのシニアリーダーであるDenis Batalovと、Alidaでgenerative AIイニシアチブを率いるSVPのDaniel Charlesと一緒に登壇しています。
これから55分ほどの間に、充実したアジェンダをご用意しています。Bedrockの基盤モデルをどのように活用できるかをご紹介します。Bedrock APIを通じて、これらのモデルをアプリケーションに簡単に組み込む方法をお見せします。また、これらのモデルを最大限に活用するためのベストプラクティスもお伝えします。そして、DanからAlidaのエキサイティングなgenerative AIの取り組みについてお話しいただきます。
基盤モデルの可能性と多様なユースケース
基盤モデルの非常に興味深い点は、多様なデータを処理できることです。例えば、テキストモデルは長文の文書、メッセージ、さらにはログも処理できます。これにより、組織内に既に存在する多くのデータを活用し、今後数年間で数兆ドルの影響を与える独自の機会が得られます。Gartnerによると、企業のデータの80-90%は非構造化データだそうです。McKinsey and Companyは、Generative AIが世界経済に4.4兆ドルの影響を与える可能性があると推定しています。
現在、開発者はgenerative AIを使用して、顧客体験を向上させ、組織内の従業員の生産性を高め、ビジネスプロセスから無駄を排除しています。例えば、小売業からSaaSプロバイダーまで、様々な組織がgenerative AIを使用して、人間の介入なしで顧客の問題を解決する自律型AIエージェントを構築しているのを目にします。また、個人が自力では作成できなかったコンテンツを作成できるようにするツールを作成しているスタートアップも見られます。そして、大量のデータ処理を含むワークフローを再考している企業も見られます。これらのユースケースをいくつか具体的な例を挙げて見ていきましょう。
Amazon Bedrockを活用したカスタマーサポートの革新
先ほど言及したカスタマーサポートは、非常に人気のあるユースケースです。これは、基盤モデルが顧客の質問に答え、フォローアップの質問をし、人間の介入なしで問題を解決するために必要な情報を取得するのに理想的に適しているからです。また、ビジネスに良い影響を与え、顧客満足度を維持する非常に迅速な方法でもあります。この例では、テキスト生成モデルを使用して、販売者から購入したテレビに問題を抱えている顧客との会話を行っています。基盤モデルを活用したAIチャットボットは、単なる注文情報からそのテレビに関する具体的な情報を調べ、わずか10回のやり取りで問題を解決するための具体的なガイダンスを提供し、販売者と顧客の両方の貴重な時間を節約します。
さて、販売者として、一人のお客様だけでなく、すべてのお客様に対するカスタマーサポート機能を向上させたいと考えるでしょう。この例では、複数の顧客からの会話記録（これはフィクションの例ですが）を foundation model に渡し、遭遇したすべての製品と問題、そしてそれらが解決されたかどうかを表にまとめるよう依頼しています。
そして、Meta Llama 2 13B model を使用してこのような表を生成しました。この表には注文情報、製品情報が含まれています。製品で発生した具体的な問題と、その解決策が示されています。販売者として、多くの顧客にわたる何万もの製品を含む表があれば、カスタマーサービス機能の改善方法だけでなく、カタログの改良方法や、サプライヤーにフィードバックすべき内容についても、素晴らしい洞察が得られるでしょう。
会話記録に話を戻しましょう。これらはデータ形式としてますます普及しています。多くの人がミーティングでコラボレーションに時間を費やしていますが、ミーティングの録音から会話記録を生成することがこれまで以上に簡単になっています。この例では、Bedrock 上の AI21 Jurassic 2 Ultra model を使用して、担当者と期日が含まれた明確なアクションアイテムのリストを作成しています。開発者として、これをさらに一歩進めることができると想像できるでしょう。この情報を抽出するだけでなく、参加者のカレンダーにTo-Doを設定し、フォローアップするアプリケーションを作成することができます。このようなアプリケーションは、おそらく誰もが時間を節約でき、より良い結果につながるでしょう。
テキスト生成モデルによる多様な業務効率化
ここでは、ブログ記事を生成する例を紹介します。product manager として、時々ブログ記事を生成する必要があります。この例では、アメリカのファッショントレンドに関するブログ記事を生成しようとしています。
私自身はあまり詳しくないトピックですが、Claude 2.0 に依頼したところ、非常に明確なアウトラインを提供してくれました。さらに調査できる具体的なサブトピックを挙げてくれており、多くの時間を節約し、強力な出発点を与えてくれます。
さて、ファウンデーションモデルは、法的契約書のような複雑な文書から特定の情報を抽出することも得意です。ここでは、Cohere Commandモデルを使用して、契約書から当事者の名前と開始日を抽出する例を示します。忙しい法律の専門家がこの情報を契約書全体で使用して、期限が近づいているものから優先的に確認すべき契約書を判断するのに役立つと想像できます。
次に、同様の機能を使用して、特に面倒なワークフローをどのようにアップグレードできるかを見てみましょう。この例では、架空のイベント会社が、クライアントが従わなければならない非常に複雑な支払いスケジュールを持っているとします。イベント会社として、同時に何百もの契約が進行中であり、顧客がサービス契約を遵守しているかどうかを追跡するのは特に困難かもしれません。しかし、これはテキスト生成モデルを使用することで簡素化されます。
この例では、Claudeモデルに顧客が契約を遵守しているかどうかを、単に彼らの取引履歴を渡すことで尋ねています。Claude Instantモデルは、彼らが遵守していないことを教えてくれます。さらに、その結論に至った過程を詳細に分析して説明してくれるので、このケースのフォローアップに役立ちます。開発者として、何百もの契約を分析し、フォローアップが必要な顧客のリストを生成するアプリケーションを構築できることは容易に想像できます。このアプリケーションを使って顧客自身にフォローアップし、場合によっては代替の支払いスケジュールを提案して支援することもできるでしょう。このようなユースケースとテキスト生成モデルの可能性は本当に無限大です。
Amazon Bedrockの多様なモデルと選択の考慮点
私たちは、Amazon Bedrock上でこれらの幅広いモデルを提供できることを特に嬉しく思っています。Anthropic、Cohere、AI21 Labsなどの先進的なAIスタートアップからのテキスト生成モデルを提供しています。また、ファーストパーティソリューションを好むお客様向けに、独自のAmazon Titanモデルも提供しています。そして、このセレクションにさらに多くのモデルを追加し続けることが期待できます。当初は3つのプロバイダーだけで製品を発表しましたが、その後Cohereを追加し、最近ではMetaのLlama 2モデルもBedrock上で使用できるようになりました。
さて、開発者の皆さんがこの選択肢を検討する際に念頭に置いておくと役立つ要素がいくつかあります。私たちの会話でよく出てくるものをいくつか紹介します。まず、開発者は、どのユースケースにどのファウンデーションモデルを使用できるかについて非常に関心を持っています。ファウンデーションモデルの良いところは、幅広いタスクに一般化できることです。つまり、ファウンデーションモデルは多くの異なるユースケースで有用です。アプリケーションの構築初期段階で特に役立つのは、テキスト生成や画像生成などのモダリティにおいて、そのユースケースが大まかにどのようなものかを特定し、アプリケーションに期待されるすべてのタスクをリストアップすることです。
オンラインで入手可能な評価研究やベンチマークを調べ、自分で実験を行って、どのモデルがあなたのアプリケーションに最適か、またはどのモデルの組み合わせがあなたのアプリケーションに使えるかを確認できます。重要な点として、モデルプロバイダーが安全性やポリシーの観点から特定の使用ケースを禁止している場合もあります。そのため、ライセンス契約を読み、利用可能な場合は、プロバイダーの利用規約を確認して、どのような用途でモデルを使用できるかを理解しておくと良いでしょう。
Foundation modelは段階的に作成されます。 まず、生のデータセットで事前学習されます。これはインターネットから収集されたデータかもしれません。その後、ラベル付きデータセットを使用して精緻化または微調整され、モデルがより人間の嗜好に合うようになります。Amazon Bedrockでは、オンデマンド推論で提供しているモデルは、すぐに使える微調整済みのタイプです。
事前学習済み、instruction-tuned、dialogue-tunedといった用語を耳にしたら、モデルカードを調べて、どのように学習されたかを少し理解しておくと役立ちます。そうすることで、モデルから何を期待できるかがわかります。パラメータ数で表されるモデルサイズは、ここ数年コミュニティで話題になっています。Foundation modelは、モデルサイズが数十億パラメータに成長したときに登場し、データの上で推論を行い、明示的に学習していないタスクを実行する能力を持つようになりました。これをfoundation model内の創発的行動と呼んでいます。しかし最近では、モデルサイズを大きくする以外にも、モデルから望ましい結果を得る方法が多くあるため、プロバイダーはモデルサイズについて言及しなくなってきています。LLaMAのように13Bモデルと7Bモデルがある場合など、モデルサイズが言及されている場合は、複雑なタスクから始める場合、より大きなモデルも試してみて、より良い結果が得られるかどうかを確認するのも良いでしょう。
開発者は、多様なグローバル顧客向けの製品を構築することに非常に興奮しています。Foundation modelは、異なる言語のデータで学習されているため、多くの異なる言語をすぐにサポートします。プロバイダーは公式にサポートしている言語を明記していない場合もありますが、実験してみると、多くのモデルが複数の異なる言語で非常に良いパフォーマンスを発揮することがわかるでしょう。ここに、Amazon Bedrockのモデルの1つを使用して、シンプルなプロンプトを20の異なる言語に翻訳した例があります。モデルカードで言語固有のベンチマークを見つけることができます。これらのモデルはプログラミング言語もサポートしているので、デバッグ、コード生成、問題修正の依頼などのタスクを実行できます。
考慮すべきもう一つの重要な要素はコンテキストサイズです。 コンテキストサイズとは、1回のリクエストで処理できる入力トークンと出力トークンの合計量を指します。Amazon Bedrockでは、4kから100kまでのコンテキストサイズのモデルを提供しています。より大きなコンテキストサイズのモデルは、長文ドキュメント処理などのユースケースに役立ちます。また、そのコンテキストサイズを利用してルールや設定を指定し、より具体的な結果を得るようにプロンプトを工夫する機会も与えてくれます。コンテキストサイズを考える際に注意すべき点は、モデルによって入力と出力のコンテキストサイズが異なる場合があることです。大きなコンテキストモデルであっても、出力よりも入力に対してより大きなコンテキストを許可する場合があります。これは、さまざまなユースケースを実験する際に考慮すべき重要な詳細です。
Amazon Bedrockの実践的な使用方法とプロンプトエンジニアリング
Amazon Bedrockの多くのモデルは、Amazon Titanモデルを含めてファインチューニングが可能です。ファインチューニングとは、独自のラベル付きデータを使用してモデルの重みを調整し、性能を向上させることです。特に、ユースケースが特定のドメインに特化しており、モデルにその文脈を本質的に持たせたい場合に役立ちます。私たちは、わずか1000件ほどのラベル付きデータでモデルをファインチューニングすることで、ベースモデルの性能を大きく上回る成果を上げているお客様を見てきました。Amazon Bedrockでは、このプロセスを簡単に行えるようにしています。データセットを指定するだけで、Amazon Bedrockがファインチューニングジョブを実行し、モデルをステージングします。そして、シンプルなAPIを使って、アプリケーションで簡単に利用できるようになります。
多くの場合、お客様から「モデルをファインチューニングするのに適したタイミングはいつか」という質問を受けます。答えは、実験してみることです。プロンプトエンジニアリングによって多くのことが達成できます。さまざまなモデルのプロンプトエンジニアリングのベストプラクティスを読むことで、かなり進歩することができます。この発表の前半で紹介した例は、すべてベースモデルを使用したものでしたが、適切なプロンプトを書くだけでかなりの機能を引き出すことができます。そのため、初期段階でこのトレードオフを検討することをお勧めします。Amazon Bedrockの選択肢に話を戻すと、私たちの目標は、 さまざまなコンテキストサイズ、機能、価格帯のモデルを提供することです。サードパーティのモデルの価格は販売者が設定し、ファーストパーティのモデルの価格は私たちが設定します。しかし、全体的な目標は、お客様のユースケースと予算に合った適切なモデルを見つけられるようにすることです。
ここに万能のソリューションはありません。多くのお客様は、特定のユースケースに対して小さなコンテキストサイズのモデルから始め、それで十分かどうかを確認することができます。基本的なQ&Aや顧客サポートには十分かもしれません。記事、研究論文、契約書などの文書に対する推論を含むより複雑なタスクには、より大きなコンテキストサイズと高い推論能力を持つモデルが必要になるかもしれません。
では、ここで私の友人のDenisに引き継ぎ、Bedrockでこれらのモデルを使用する方法をお見せします。
Alidaにおけるgenerative AIの活用事例
ありがとう、Usman。私たちは、もう一つの興味深い例を見ていきます。生成AIが可能にする魅力的なユースケースは本当にたくさんあります。 今回のケースでは、映画の全台詞を記録したトランスクリプトを取り上げ、広告用のサマリー、つまり一種のあらすじを作成してみます。また、特定のペルソナに合わせてパーソナライズすることも試みます。これは、映画のタイトルなどを含む多くの対話が収録されているCornell Movie-Dialogs Corpusに基づいています。これから紹介するコード例は、Amazon Bedrock Workshopのサンプルを基にしているか、含んでいます。このワークショップは、Bedrockの使用を開始するのに最適な方法です。要約、テキスト生成、分類など、Bedrock workshopにある多くの異なる例を見ることをお勧めします。
これはトランスクリプトです。実際、この例では映画「10 Things I Hate About You」のトランスクリプトを使用します。これは可能性の1つに過ぎません。私がこのコーパス全体をダウンロードしたと想像してください。ここではPandasのDataFrameを使用しています。DFには実際に映画データセット全体が含まれています。このDataFrameの内容を見ることができます。映画のタイトル、大量のダイアログ、さらにはたくさんのジャンルがあります。このデータセットから主要なジャンルだけを選びます。「10 Things I Hate About You」を選んで、タイトルを表示し、その映画のダイアログの冒頭部分を実際に表示します。
素晴らしいですね。次に、ここでBedrockクライアントを作成します。先ほど言及したBedrockワークショップからutilsモジュールを使用します。いくつかのものをインポートしているのがわかります。もちろん、boto3もインポートします。そしてBedrockクライアントを取得し、ヘルパー関数を作成します。このクライアントを複数回呼び出すつもりだからです。この関数では、Bedrockランタイム、プロンプト、Bedrockのランダム性を制御するパラメータ（temperature、top_k、top-p）、そして生成するトークン数を渡します。これらは短い要約を生成しようとしているので、200に制限します。stop_sequencesについては後で触れます。この関数では実際にAnthropic Claude v2モデルを使用していることがわかります。
このセルを実行したところ、Bedrockクライアントが生成されました。これで、Bedrockを様々なユースケースで使用または実行するのに必要なものがすべて揃いました。まず、かなり素朴なプロンプトの試みを行います。実際、LangChainライブラリからプロンプトテンプレートクラスを使用します。Pythonでプロンプトの一部を置き換えるのに便利だからです。この場合、transcriptは潜在的に大きなテキストの一部です。そこで、「以下のトランスクリプトに基づいて映画の説明を書いてください」と言います。transcriptという変数があり、そしてクライアントを実行します。しかし、待ってください。Bedrockがvalidation exceptionを表示しています。これは、Claude v2の場合、より良い結果を得るためにプロンプト内でhumanとassistantタグを使用するのがベストプラクティスだからです。これはClaudeのベストプラクティスの一部です。そのため、Bedrockはすぐにそこに到達するよう私たちを助けています。
さて、素朴な試みはうまくいきませんでしたので、次のバージョンのプロンプトでもっと良くしてみましょう。今度は実際に、プロンプト内でトランスクリプトがどこにあるかを明確にするために、トランスクリプトをトランスクリプトタグ内に含めます。また、ネタバレを避けるように指示し、「若い女性にとって興味深い」とも言っています。これはすでにこのデモで特定の層をターゲットにしようとしています。そして、実際の言葉遣いを見ると、おそらくこの層に訴えかけるものになっていることがわかります。学校で一番人気のある男の子、規則にこだわる父親、などです。ある意味、マッチしていると言えるでしょう。しかし、次はプロンプトの別のバージョンに切り替えて、ペルソナをパラメータ化してみます。プロンプトに好きなペルソナを簡単に代入できるようにします。そこに変数を追加します。そして今度は、「20代の若い男性」を使用します。再び「10 Things I Hate About You」です。一部の人々はこれを女性向けの映画と言うかもしれませんが、この新しい層に対してこのプロンプトが何を生成するか見てみましょう。
これは、このプロンプトの実行にかかる実際の時間を示しています。Amazon Bedrock が読み込む必要のある長いトランスクリプトです。そして今、 異なる用語が使われ始めているのが分かります。例えば、「人気のあるジョックとプロムに行く」「反抗的なパンクロッカー」「バッドボーイ」などです。他のものも混ぜ込んでいるようですね。同じトランスクリプトで、異なるペルソナにカスタマイズできるのは興味深いです。ただし、ここで1つ気になる点があります。この広告について気にしていますが、最初の部分はあまり気にしていません。これが127語のプロンプトです。私はただ要約を取り出して、どこかに置きたいだけなのです。
そこで、この新しいプロンプトでは、 いわばClaude の口に言葉を入れようとしています。ここでプロンプトを見ると、「Markdown を使用して広告をフォーマットし、ad タグの間に出力してください」と言っています。もちろん、ここでも私は Claude の口に言葉を入れています。なぜなら、assistant の応答を 「ここに広告があります」という開始タグで始めているからです。そして、タグを閉じるためのストップシーケンスを設定し、その間に生成されたものだけを出力する必要があります。 そして今度は、Heath Ledger の作品のファンである中年女性のペルソナに変更しています。どんなものが生成されるか見てみましょう。
実際、少し長めかもしれません。次は、もう少し簡潔にするか、プロンプトを提供する必要があるかもしれません。しかし、ここで興味深いのは、このモデルが映画を認識したことです。私たちは実際にどの映画かを言及していませんでした。これが「10 Things I Hate About You」だと認識しました。また、Heath Ledger がこの映画で演じている役も知っています。これには長所と短所があると思います。一方では、その知識が使われたのは素晴らしいことですが、この場合、幻覚の可能性もあります。Heath Ledger ではなく他の俳優を使用した場合、おそらくその俳優が実際にトランスクリプトの中の何らかのキャラクターを演じたかどうかを確認しようとし、映画を認識できない可能性があります。そのため、ここではおそらくもっと作業が必要だと思いますが、Amazon Bedrock を使用してこれらの異なるプロンプトの上に徐々に構築していく進歩も見ることができます。
まとめると、 異なるモデルには異なるプロンプトが必要です。一つのサイズがすべてに適合するわけではないのは明らかです。私たちは本当に、どのモデルを使用しているかを知る必要があります。プロンプトガイドを見る必要があります。そして、このプロンプトエンジニアリングという職務について言及すべきことがあります。時々冗談を言いたくなるほどですが、なぜなら知っておくべき特殊な事項があり、これらのモデルがどのように訓練されたか、モデルの事前訓練中にどのような指示が提供されたかを理解する必要があるからです。そう、これが重要なポイントです。では、実際にこれが重要となる他の例をいくつか見てみましょう。
質問応答タスクを見てみましょう。そして、これも先ほど見たのとまったく同じことを示しています。human と assistant を言わないと、検証例外が発生します。そのため、単純なプロンプトはおそらく機能しません。そして今、正しい構造を使用し、正しいテンプレートを使用して、望んでいた結果を得ています。これが Claude です。すでに見てきました。しかし、例えば Llama 2 に切り替えると、 異なるプロンプトのセットが現れます。興味深いのは、よく知らないと、プロンプトの単純な試みが幻覚などを含む奇妙な結果につながる可能性があることです。しかし、ガイドを読むと、INST タグの中に発話を組み込むことが推奨されています。
これは特に、複数のターンを含むチャット会話がある場合に重要です。また、SYSタグの部分を使用して、モデルが使用すべきトーンや、適用すべき追加の特性や制約を示し、ガイドすることもできます。
これに対して良い反応が得られています。また、興味深い文脈情報もあります。質問は単純に見えるかもしれませんが、実際には微妙な点があります。月までの距離は一つではありません。その違いは重要で、あなたが気にしているかもしれません。
Titanについても同じことが言えます。驚くかもしれませんが、単純な質問のように見えて、モデルが正しい答えを知っているにもかかわらず、「わかりません」という非常に簡潔な回答が得られることがあります。推奨されるのは、userとassistantのようなものを使用することで、求めていた正確な答えが得られます。
分類についても見てみましょう。要約は、デモで見たような、サマリーのテキスト生成のようなものです。しかし、分類を見ると、この長い文章を取り、「AIアシスタントへようこそ、どのようにお手伝いできますか？」「こんにちは、購入について助けが必要です」「はい、注文IDを教えていただけますか？」などと読むことができます。このように会話全体の記録があり、それを単にラベル付けしたいのです。情報収集についてですか？フィードバック、サポート、その他ですか？単一のタグで、分類は何かを教えてください。
素朴なアプローチとして、humanとassistantもどこかにあると仮定できます。表示するには長すぎるだけです。個々のフレーズや発言の分類が得られます。最初のものは情報に関するもので、他のものはフィードバックに関するものかもしれません。これは本当に私たちが求めているものではありません。私たちが欲しいのは、全体的な単一のクラスだけです。
適切なプロンプトを使用することで、「これが質問で、これらがカテゴリーです」と言って、1つのカテゴリーに従って分類すると、正解として「サポート」が得られます。他のモデルについても見てみましょう。LLaMAの場合、同等のバージョンであるLLaMA 2では、次のように表示されます。 ここでも、ターンごとの分類ではなく、カテゴリーとしてサポートが選ばれています。 そして、Amazon Titanでも同様です。サポートについて、簡潔で明確な回答が得られています。
ある意味で明らかな結論ですが、プロンプトテンプレートを設計する必要があります。LangChainのプロンプトテンプレートを使用するなど、Bedrockと統合する簡単な方法から始めるのがよいでしょう。多くの異なるタスクでテストを行い、実際の使用ケースでは最も性能の良いものを選び、モニタリングし、繰り返し改善していく必要があります。つまり、ベストプラクティスとモニタリングが重要な概念となります。
さて、ここでDanに引き継ぎます。彼はAlidaで行った興味深いgenerative AIアプリケーションについて話してくれます。
Alidaのプラットフォームとテキスト分析の課題
ありがとう、Denis。私はDaniel Charlesで、AlidaのSenior Vice President of Product and Go to Marketを務めています。今日は、Amazon BedrockとAlidaの人間中心のgenerative AIを使って、私たちがどのようにインサイトを革新したかについてお話しします。まず、Alidaについて少しご紹介します。次に、generative AI以前のテキスト分析の課題について話し、そしてgenerative AIとAmazon Bedrockで何を行ったか、私たちのgenerative AIソリューションの内部構造についてお話しします。最後に、Alidaにおけるgenerative AIの将来について、なぜ私たちが非常に興奮しているかをお伝えします。
では、早速始めましょう。Alidaは、コミュニティ中心のカスタマーリサーチプラットフォームです。 HBO Max、Hulu、X、Lululemon、Volvo、Jam Cityなどの企業が、より良い製品とユーザー体験を構築するために、顧客に関する定性的および定量的なフィードバックを収集することができます。私たちのプラットフォームには、全体で1億7600万人以上の検証済みで積極的な回答者がいます。そして、このプラットフォームは毎月何百万人もの人々によって成長を続けています。
私たちは、Gartnerによって Voice of Customer (VOC) 分野のリーダーとして認められています。当社のお客様は、アンケートやその他のタイプのアクティビティを通じて、多くの定性的・定量的なフィードバックを収集しています。優れたテキスト分析ソリューションを提供するためには、様々な種類のデータを私たちのシステムに取り込む必要があります。
まずは、次のテキストから何が読み取れるか見てみましょう。このコーヒーショップをご存知かもしれません。これらのレビューはインターネットから取得したものです。このレビューを見てみましょう：「そうだね」とStarbucksのスターは言います。「Starbucksは、ヒップホップアーティストとしての僕のお気に入りだよ。困難な時期を乗り越えさせてくれる。唯一の問題は、アプリが時々フリーズすることかな。」ここから、この人がStarbucksの大ファンであることは明らかです。彼は5つ星の評価をつけています。Starbucksは彼のお気に入りのコーヒーショップで、彼はヒップホップアーティストで、アプリに少し問題があり、高額を使う顧客で、クリスマスプロモーションと一部の特典について問題があったようです。
彼はもっと多くのものが手に入ればいいと思っています。リワードプログラムからもっと多くのものが手に入ればいいと思わない人はいるでしょうか？最後に、クリスマスプロモーションに不満を持っていました。なぜなら、1万ドルも使ったのに何も当たらなかったからです。Starbucksで1万ドルも使って何も当たらないなんて想像してみてください。また、句読点がなく、スラングがたくさん使われています。
では、generative AIが存在する前、あるいは私たちがgenerative AIについてよく知る前の24ヶ月前に、これをテキスト分析エンジンにかけたらどうなっていたでしょうか。IBM WatsonとAmazon Comprehendを見てみました。これらのモデルを訓練して良い結果を得ることなく、全体的な感情は否定的だという結果が出ました。明らかにStarbucksの大ファンであるのに、感情が否定的であるはずがありません。しかし、肯定的なコメントよりも否定的なコメントの方が多いので、モデルはそのように判断したのかもしれません。
多くのキーワードが抽出されました。ヒップホップアーティスト、Starbucks、日、半分、アプリ、困難な時期。これらは特にアクションにつながるキーワードではありません。トピックもありません。コンテキストについての理解もありません。そのため、このような意味不明なキーワード分析が行われ、コンテキストを区別する能力がないのです。
私たちの生成AIモデルは文脈を理解し、これがアプリのレビューであることを理解します。私たちには手間のかかる分類体系があります。そのデータをどのようにラベル付けするか、例えばカスタマーサービス、技術的な問題、あるいは製品の品質といったラベルを付けたいと考えるかもしれません。生成AI以前の世界では、そのためにはカスタマー向けに複数の例でモデルを訓練する必要がありました。おそらくCSATのようなものですが、各顧客ごとに一回限りの作業をしない限り、実際にそこから価値を抽出することはできませんでした。
Amazon BedrockとClaude 2を用いたAlidaの新しいテキスト分析エンジン
最後に、すべてを英語に翻訳する必要がありました。「Hey Jude、そんなに思慮のないことはやめなよ。悲しい歌を作って、それをもっと良くしていこう。心に抱えることを忘れずに、そうすればもっと上手くやれるようになるよ」。英語と他の言語の間で行ったり来たりと翻訳を繰り返すと、歌の意味の多くが失われてしまいます。そのため、実際の文脈を理解することができません。新しいモデルは複数の言語にわたって言語を理解します。そのため、以前のような言語の壁はもはやありません。
では、私たちは何を構築したのでしょうか？ Amazon Bedrockに新しいテキスト分析エンジンを構築しました。それにはAnthropicのモデルを使用しました。これからすぐに分かることは、アプリのフィードバックには幅広い分布があり、ネガティブなもの、中立的なもの、ポジティブなものがあるということです。そしてこれは予想通りの結果です。私たちは、分析しているデータがどのような種類のものかについて、何のコンテキストも与えていませんでした。モバイルアプリの体験について、ポジティブとネガティブがあります。これらは感情分析の観点からとても良い結果です。
ログインの問題に掘り下げてみると、ここでの全コンテンツの約7〜8%がログインの問題であることがわかります。そのデータをさらに掘り下げると、ログインの問題が見つかりました。これは製品やユーザー体験の担当者として非常にアクションにつながる情報です。どうすればそのログインの問題を解決できるでしょうか？顧客がアプリのログインで直面している問題はどのようなものでしょうか？実は、人々はよくパスワードを忘れてしまうのです。また、匿名版を望んでいるためにログインできないこともあります。そこから掘り下げて、それらの問題を修正し、すぐにビジネスに価値を還元することができます。これらは今や、エンジンに指示を出して取り組むことができるアクションにつながる情報であり、私たちが対応している顧客の問題を解決したり、問題解決を支援したりすることができます。
これは、一見ランダムに見えるキーワードを使っていた頃には不可能でした。Amazon Bedrockを使用した私たちのダッシュボードでは、これまでのところ素晴らしい結果を得ています。
それでは、この機能をどのように実現したのか、少し詳しく見ていきましょう。先ほどのStarbucksの例に戻ります。Amazon Bedrockに何を尋ねたのでしょうか？ Claude 2モデルを使用して、Amazon Bedrockに、ユーザーが言及しているアプリの各側面について、-1から1のスコアで感情分析を行い、特定のJSON形式で結果を返すよう依頼しました。これにより、システムで解析し活用できるようになります。
では、結果はどのようなものでしょうか？ おそらく想像できると思いますが、Amazon Bedrockはすぐにこれを肯定的な感情として判断しました。もちろん、肯定的な感情です。彼は1万ドルも使っているし、Starbucksが大好きだと言っています。他の文脈は与えていません。Starbucksのコーヒーは肯定的な感情を持っています。モバイルアプリの機能については、いくつか課題があるようで、これは対応すべき事項です。リワードプログラムについては、少し不満があるようです。ほぼ中立的な評価です。そしてクリスマスプロモーション - 誰もがクリスマスプロモーションで勝ちたいと思っています。
では、私たちが直面した課題は何だったでしょうか？ まず、このようなモデルを扱う際に、トピックのリストをどのように絞り込むかという問題がありました。AmazonとPrompt 100プログラムの助けを借りて、トピックのリストをより細かくし、同時により大まかにする方法を見出しました。エンベディングとクラスタリングを使用して、トピックの数を意味のある集合に絞り込みました。
次に、APIレスポンスの一貫性について検討しました。これはどういう意味でしょうか？確率的なモデルを扱っているため、「コーヒーが好きではない」や「今日はひどい経験をした」といった文章が、ある時は「悪いコーヒー」というトピックになり、別の時は「カスタマーサービス」というトピックになることがあります。毎回同じ結果を得るにはどうすればよいでしょうか？私たちは、トピックのリポジトリを構築し、それらのトピックを既に特定されたトピックにマッピングすることで、同じテキストでAPIを呼び出すたびに同じ結果が得られるようにしました。
最後に直面した課題は、APIのレート制限でした。この点については、AmazonがBedrockのレート制限を引き上げてくれたので大変助かりました。APIを呼び出す際にもう一つ考慮すべき点は、特に大規模な場合、かなりコストがかかることです。私たちは膨大な顧客データ、すべての定性的データを送信しています。リクエストをバッチ処理することで、この問題を回避できることがわかりました。プロンプトは1対1の比率である必要はありません。複数のレビューを同時に送信し、それらの結果を一度に受け取ることができました。
これらは、後で製品の詳細を作成するために人々が使用する実用的な洞察です。このような洞察に基づいて行われる製品の詳細やユーザー体験の変更はリアルタイムではありません。そのため、リアルタイムで取得する必要はなく、バッチ処理が私たちにとって非常に良いソリューションでした。
Alidaのgenerative AI活用の成果と今後の展望
全体として、Amazon BedrockとClaude 2の使用には大変満足しています。モデルを何度も再トレーニングすることなく、文脈理解を向上させることができました。一般的なフィードバック、アプリの体験、アプリの問題点、アプリの使いやすさなど、これらはすべて今日お見せした例からモデルが抽出したものです。このように、メンテナンスの少ないタクソノミーが私たちのビジネスに価値をもたらしています。
また、新しい顧客を迎えるたびに モデルをトレーニングする必要もありません。これについて考えると、金融サービス、メディア、テクノロジー、ヘルスケアなど、さまざまな業界に顧客がいます。彼らにはそれぞれ異なるニーズがあり、得られる回答のタイプも異なります。汎用モデルを使用することで時間を節約でき、より迅速に展開して、収集される定性的データが異なる様々な業界の顧客全てに対して優れた結果を得ることができます。
最後に、先ほど私が行ったり来たりで翻訳したBeatlesの曲を覚えていますか？ 実は、言語の壁を乗り越えることができるのです。ClaudeとAnthropicは、フランス語からドイツ語、スペイン語まで、西洋言語を本当に上手く扱います。私たちの顧客はこれらの様々な地域で事業を展開しています。データをプロンプトで与える際、モデルはそのデータを英語やフランス語、スペイン語に翻訳しません。データをネイティブ言語で入力でき、そしてその言語のネイティブスピーカーのように、トピックを抽出できますが、それを私たちの基本言語（英語かもしれませんし、顧客によってはフランス語やスペイン語かもしれません）に戻して抽出します。顧客は基本言語を使用でき、他の言語を理解する必要がありません。これは、私たちが日々取り引きしている多国籍ブランドにとって非常に有効です。
では、次に何をするのが最も楽しみかというと、テキスト分析エンジンで 生成するタグやトピックをユーザーがより細かく制御できるようにすることです。彼らのトピックでモデルをトレーニングし、データのクラスタリングを開始し、埋め込みを構築して、モデルが生成するトピックをカスタマイズできるようにします。次に取り組むのは、人々からデータを収集するために送信するアクティビティ、調査、その他のタイプのアクティビティに関連することです。以前は、多国籍ブランドが私たちの調査プラットフォームを使用する際、それらの調査を複数の言語に翻訳するために第三者に依頼する必要がありました。今では、プラットフォーム上でボタンをクリックするだけでそれが可能になります。つまり、翻訳機能は、複数の市場に展開できるコンテンツを作成し、様々な回答者から幅広くフィードバックを得る上で非常に有用なものとなるでしょう。
次は要約についてです。要約は非常に興味深いものです。私たちはさらに多くのことを構築していく予定です。定性データについては素晴らしい仕事をしてきたと思いますが、人々は定量データの要約も始めたいと考えています。先ほどのDenisとUsmanのプレゼンテーションでデータ抽出の一部を見ましたが、私たちはプラットフォームでそのデータのより良い要約を行いたいと考えています。最後の点は本当に興味深いです。このショーの後、AIM333についてのアンケートを受け取ったとします。そのアンケートで「AIM333はどうでしたか？」と聞かれ、あなたが「素晴らしかった」と答えたとします。単に「素晴らしかった」という回答だけでは、あまり分析できることがありません。しかし、エンジンが「なぜ素晴らしいと思ったのですか？」とプロンプトを出せるとしたらどうでしょうか。
私たちはこれを実験してきました。まだユーザーインターフェースについては完全に解決できていませんが、次のようになるかもしれません：「なぜ素晴らしいと思いましたか？」「多くの本当にクールなユースケースをカバーしていたからだと思います。」そして、「どのユースケースが一番良かったですか？」と聞くと、「Alidaのユースケースが信じられないほど素晴らしかったと思います。」と答えるかもしれません。このようなオープンエンドのプロンプトについて、私たちはかなり興奮しており、アンケートの回答方法を変革する可能性があると考えています。では、Denisに戻して、まとめをしてもらいます。
Amazon Bedrockにおける責任あるAIの実践
Dan、ありがとうございます。これは非常にクールで実用的なアプリケーションだと思います。これらの生成システムが可能にすることを見るのは興奮します。過去2年間、私個人的にはresponsible AIに焦点を当ててきました。生成AIが全面的に登場する前から、これらの機械学習モデルとAIシステム全体を責任を持って構築することがいかに重要であるかは明らかでした。そこで、締めくくりとしてそのことについて少しお話ししたいと思います。まず、Amazon Bedrockで私たちが講じたすべてのコントロールと対策について認識していただきたいと思います。まず第一に、データの管理はお客様が行うという明確な声明を出しています。
モデルに入力されるもの、モデルから出力されるもの、私たちはその情報を保存しません。実際、その情報を自分のニーズのためにログに記録したい場合は、例えばCloudWatch logsと統合するなどのソリューションが必要です。S3バケットをセットアップして結果をそこに置くこともできます。これらの側面について話すことは非常に重要です。
データの暗号化や、データがお客様の仮想プライベートクラウドから出ないようにすることについてはどうでしょうか？AWS PrivateLinkがあり、Amazon Bedrockをお客様自身のVPCとリンクする機能があります。これは明らかに非常に重要な考慮事項です。そしてもちろん、AWS Identity and Access Management (IAM)コントロールを期待できますし、AWS CloudTrailを使用してAPI活動を監視し、誰がいつAPIを呼び出したかを追跡することもできます。これは、ある意味でAWSサービスの基本的な機能ですが、Amazon Bedrockで利用可能であることを強調することが重要です。データを暗号化している場合、または顧客管理キーで暗号化することに慣れている場合、これはBedrockで完全にサポートされています。つまり、CMKがあり、どのキーで暗号化するかはお客様が決定します。
今朝のキーノートを聞いたり、参加したりした方はどれくらいいらっしゃいますか？ Amazon Bedrock用のGuardrailsをローンチしたことをご存知でしょう。これは実際、とてもエキサイティングで長年待ち望まれていた機能セットです。モデルの特定の特性についてコントロールや検証、さらにはベンチマークを取る能力が必要だということはご存知でしょう。しかし、さらに重要なのは、システムを実行している際にリアルタイムでコントロールを行う必要があるということです。
Amazon Bedrock Guardrailsでは、非常に興味深い機能が提供されています。よく、プロンプトや、これらのモデルからの出力の有害性について話題になりますが、もちろん、そういったことが起こらないようにする必要があります。モデルがどんな形であれ不快な思いをさせないようにすることは、当然の期待です。Bedrock Guardrailsは複数のコンテンツフィルターを提供しています。ご覧のように、憎悪、侮辱、性的内容、暴力に関するフィルターがあり、これらはモデルに入力されるプロンプトと出力される結果の両方に対して、様々なレベルで指定することができます。
また、非常に興味深い機能として、トピックの概念があります。これは実際、「これらのモデルを特定の会話や、私が関心を持っている特定のトピックの範囲内に留めたい」と言っているのです。ビジネスを運営している場合、カスタマーサポートや、立ち上げているチャットボット、Q&Aシステムなどが、自分の事業に関連することに答えてほしいと思うでしょう。ランダムな話題について会話してほしくありません。もちろん、標準的な使用、質問や回答の中で政治的な話題が出てくることは望ましくありません。
ここでの例は投資アドバイスです。投資アドバイスを避けたいと思います。トピックをタイトルで指定するだけでなく、避けたいことについてより詳細な説明や定義を自然言語で提供します。サンプルのプロンプトと最終的な応答を見ると、この場合はすべて問題ありませんでした。これらのトピックは検出されませんでした。しかし同時に、明確にトリガーすることもでき、特定のトピックが検出された結果、拒否されたことがわかります。また、「これについてはコメントできません」や「この話題について議論するのは気が進みません」などの特定の最終応答を出すこともできます。これらを完全にコントロールすることができるのです。
Amazon Bedrockの学習リソースと今後の展開
最後に、いくつかのリソースをご紹介して締めくくりたいと思います。Amazon Bedrock Getting Startedコースがあります。これはTraining and Certificationから提供されています。そちらでBedrockの使い方を学んでください。そして、もちろん先ほど言及したAmazon Bedrock Workshopもあります。繰り返しになりますが、異なるモデルや異なるアプローチを用いた多くの興味深い例が用意されています。
例えば、これらの長い transcript の要約については、Claude のようなものを使えば、大きなコンテキストウィンドウが可能なので、非常に大きな transcript を渡すことができます。しかし、ここでもまた経済性を考慮する必要があります。他のアプローチとしては、実際にその入力を複数のセクションに分割し、より小さなコンテキストを扱えるモデルに供給し、その後で要約を集合的に組み合わせるという方法があります。
そして、もちろん、machine learning 側からの刺激的な発表については全て、ブログ記事をご覧ください。リンクがあるはずですが、単に Google で Amazon AI-ML blogs を検索してください。例えば、先ほど話した Amazon Bedrock Guardrails についてのブログ記事がすでに公開されています。X で私や Usman に連絡する方法もありますが、session survey の記入も忘れずに。そして、Alida がそれをどう扱うか試してみるのも面白いでしょう。 どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion