re:Invent 2024: AWSでのGenerative AIソリューション開発事例 - Buy with Prime
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building and releasing robust generative AI solutions on AWS (BWP302)
この動画では、Buy with PrimeとMerchant Assistantという2つのGenerative AIソリューションの開発事例が紹介されています。Amazon BedrockとKnowledge Base、Action Groupsを活用したアーキテクチャの詳細や、自動評価の手法、トレーサビリティの確保、セキュリティ対策など、実践的な知見が共有されています。特にPrompt Injection対策やOver-reliance、機密情報漏洩などのAI特有のセキュリティ脅威への対応や、Amazon Bedrockの組み込みGuardrailsの活用方法について具体的に解説されています。また、bareMineralsの事例では、Buy with Prime導入後に訪問者あたりの収益が40%増加したという具体的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIの課題と本セッションの概要
みなさん、こんにちは。本日のセッションへようこそ。まず最初に、みなさんにお聞きしたいのですが、Generative AIを試してみた方、あるいは現在使用している方は何人いらっしゃいますか？きっとほとんどの方がそうだと思います。Generative AIは刺激的なフロンティアであり、その進歩の速さには目を見張るものがあります。朝にソフトウェアをアップデートしたと思ったら、お昼には不具合が修正され、新機能が追加されているようなものですね。このジョークはあまりウケなかったようですね。私のモデルもちょっとFine-tuningが必要かもしれません。
開発者にとって、Generative AIは刺激的であると同時に圧倒されるような存在です。ブログ記事やホワイトペーパーを読んだり、動画を見たり、さまざまなシリーズから学んだりして、かなり decent な理解を得ることができます。実際、何かを作れそうだという自信も湧いてきます。しかし、実際に開発を始めると、多くの選択肢やソリューション、モデルアプローチが存在するため、大きな課題に直面します。「どうやって」や「何を」に気を取られすぎて、「なぜ」を考えることを忘れがちです - なぜこのアプローチが以前のものより優れているのか？なぜこのソリューションが他のソリューションより優れた実装なのか？なぜこのモデルやRAGを他のモデルより選んだのか？
そこで気づくのは、各意思決定の背後にある深い「なぜ」を理解することが、Generative AIの複雑さに対処し、堅牢なソリューションを構築する上で極めて重要だということです。そこで本日は、私たちが最近ローンチしたソリューションから得た実践的な知見と、その「なぜ」についてご紹介したいと思います。このソリューションは、すでに顧客に大きなインパクトを与えています。本題に入る前に、共同発表者を紹介させていただきます。 Ayush ChughはShopper Assistantソリューションの構築の最前線で活躍しています。Sebastian LipnickiはMerchant Assistantソリューションを生み出した立役者です。そして私、Zubeen SahajwaniはBuy with PrimeとMCFのSenior Solutions Architectです。正直に言って、私は彼らほど賢くありませんが、Solutions Architectとしての私の役割は、お客様がこれらの革新的なソリューションを採用・実装する際のサポートを行い、即座の目標達成だけでなく、長期的な目標との整合性も確保することです。
さて、自己紹介が済んだところで、本日のトピックに入っていきましょう。まず、Buy with Primeの紹介から始めて、これがお客様のショッピング体験をどのように変革しているかを探ります。次に、最近ローンチしたGenerative AIソリューションをご紹介し、それがDTCビジネスにどのようなイノベーションをもたらしているかをお話しします。また、Generative AI導入前後での経験の違いや、導入後にもたらされた大きな影響についても共有します。その後、設計、開発、評価について説明し、主要な要件と、堅牢なGenerative AIソリューションを提供するためにどのようにバックワードワークしたかを見ていきます。最後に、Generative AIプロジェクトの効果を最大限に引き出すためのベストプラクティスについて詳しく説明します。
Buy with Primeの紹介とショッピング体験の変革
それでは始めましょう。まず、なぜ私がBuy with PrimeのようなAmazonの販売チャネルについて話しているのか疑問に思われるかもしれません。約45年前、私たちは多くのブランドが選択を迫られているのを目にしました - DTCに完全に注力するか、Amazon.comのようなマルチブランドリテーラーに完全に注力するかのどちらかでした。しかし、ブランドはすぐに、消費者が自社のウェブサイト、eコマースマーケットプレイス、ソーシャルメディアサイトのどこにいても、より近い関係を築く必要があることに気づきました。私たちも、サプライチェーンとeコマースサービスを外部に提供することで、これらのブランドを支援できる素晴らしい機会があることに気づきました。 Amazonは物流ネットワークに数十億ドルを投資してきました。これにより、マーチャントは私たちのネットワークを利用して、Amazon.comの注文だけでなく、すべての消費者の注文を処理することができます。これがAmazon Multi-Channel Fulfillmentです。
米国では20万以上の販売事業者が、様々な販売チャネルにおける消費者注文の集荷、梱包、配送にこのサービスを利用しています。ブランド独自のウェブサイトについては、Buy with Primeを通じて、ショッパーにPrimeの配送サービスを提供できるようになりました。 このサービスにより、ブランドは業務を効率化しながら、ショッパーを惹きつけ、売上を伸ばすことができます。
では、現在どのように機能しているのか見ていきましょう。消費者の買い物の仕方は変化しており、これは特にbareMineralsのような美容業界のブランドで顕著です。 例えば、ショッパーがインフルエンサーの投稿をきっかけにbareMineralsの商品を購入しようと考えるシナリオを想像してみてください。 ソーシャルメディアから直接bareMineralsのウェブサイトに移動すると、 Prime配送対象商品には青いPrimeチェックマークロゴと共に、超高速配送の正確な到着予定日が表示されます。商品詳細ページでは、 ショッパーはPrimeメンバーシップを使って無料配送でチェックアウトすることができます。bareMineralsは Amazon.comに掲載されている商品の評価やレビューを自社の商品詳細ページに組み込んでおり、ショッパーが迅速かつ確実な判断を下し、ブランドと商品に対する信頼感を持てるようサポートしています。
注文が確定すると、bareMineralsの在庫は Amazonのフルフィルメント在庫に組み込まれ、商品は消費者の玄関先への迅速な配送の旅を始めます。これは彼らのビジネスにどのような影響をもたらしたのでしょうか？ Buy with Primeを導入後、bareMineralsはショッパーのコンバージョン率が向上し、 訪問者あたりの収益が40%増加しました。ここにいる多くの方がPrimeメンバーだと思いますが、 オンラインショッピングをする場所がどこであれ、Primeのショッピング特典を受けられることを想像してみてください。これが私たちのビジョンです - より多くの場所でより多くのPrime対象商品を利用できるようになることを、誰が望まないでしょうか？
AIを活用した販売事業者サポートとショッパーアシスタントの実装
これを実現するために、私たちは大手企業と協力して、フルフィルメントからリマーケティングまで、ブランドのeコマースジャーニー全体にBuy with Primeを統合しています。Buy with Primeは、Shopify、Salesforce、 ソーシャルメディアなどの企業向けプラットフォームに対して、様々な統合オプションを提供しています。DIYアプローチを好む販売事業者向けには、カスタムダイレクトAPIオプションも用意しています。全体を見渡すと、 Amazonは多くのサービスを提供しており、各サービスにはそれぞれ独自の統合パターンがあります。販売事業者にとっては、サービスについて読み、サービスの異なる側面を理解し、統合パターンを把握することは大変な作業になり得ます。
ここで、販売事業者が情報をより迅速かつ正確に見つけられるようにする販売事業者アシスタントAIソリューションについて、同僚に説明してもらいましょう。先ほど述べたように、 AmazonとBuy with Primeは販売事業者に多くのサービスを提供しており、様々な統合パターンがあります。販売事業者がどの統合パターンが最適かを判断できるよう、販売事業者サポート ナレッジセンターを設けており、そこで販売事業者はクエリを入力することができます。このキーワードベースの検索エンジンは通常うまく機能しますが、いくつかの制限があります。例えば、販売事業者がBuy with Primeの価格設定について理解したい場合、キーワードベースの検索エンジンは「Buy with Prime」を含むすべてのリソースを検索しますが、それらが必ずしも価格設定に関連しているとは限りません。
体験を向上させるため、私たちはAIソリューションを導入しました。これにより、マーチャントは質問を投げかけることができ、AIがその質問の意味や意図を理解して、要約された形で関連する回答を提供します。Buy with Primeの価格設定の仕組みについて、マーチャントが質問するケースを例に見てみましょう。
価格設定には3つの手数料があります：Primeサービス手数料、フルフィルメント手数料、決済処理手数料です。マーチャントがオンボーディングを完了した後、カタログの同期に問題が発生した場合、AIが正しいカタログ同期のために必要な具体的な手順を案内します。
マーチャントが直面する最大の課題は、カスタマーコンタクトの対応です。マーチャントは、注文の配送状況や到着予定日、返品や交換方法について、多くの問い合わせをショッパーから受け取ります。マーチャントをサポートするため、私たちは24時間365日対応のカスタマーサポートソリューション「Buy with Prime Assist」を提供しています。具体的な仕組みはこうです：ショッパーが注文を行うと、サポートウィジェットを備えた注文後ページが表示されます。ショッパーは右側のボタンをクリックして、注文後の問い合わせについてサポートを提供するカスタマーサービス担当者に連絡することができます。
このシステムは注文後のサプライチェーン関連の問い合わせのほとんどに対応できますが、製品固有の質問も多いことがわかりました。例えば、Apollo Wearableを購入した人が製品について質問がある場合などです。当初は、マーチャントに直接メールを送信し、マーチャントが返信する方法を採用していました。この方法には欠点がありました - ショッパーはマーチャントからの返信を待たなければならず、マーチャントは返信のために時間と労力を費やす必要がありました。これが当初の体験で、例えばMuktiというショッパーがApollo Neuroから商品を購入し、このフォームを通じてマーチャントにメールを送る必要があったのです。
この体験を最適化し、ショッパー体験を向上させるため、私たちはAIソリューションを実装しました。このAIソリューションがどのように機能するか見てみましょう。チャットボット体験に接続するには、ショッパーは適切な意図を選択し、質問を直接入力するだけです。例えば、ウェアラブル端末をスマートフォンに接続する方法について質問がある場合、それを入力するだけで、次の質問をする前にすでに回答が得られます。これは、AIからの応答がいかに迅速であるかを示しており、ショッパーがさらに詳しく知りたい場合は、それに応じて進めることができます。
その後のやり取りでは、ショッパーは質問を入力するだけで即座に回答を得ることができます。これはショッパー体験の大きな改善となります。さらに、ショッパーは注文のステータス確認や配送時期など、注文に関するあらゆる質問をすることができます。 基盤となるAIは意図を理解し、適切なサービスを呼び出して、ショッパーへの回答を生成します。例えば、ショッパーが注文の到着予定を尋ねた場合、AIはその意図を理解し、必要なAPIを呼び出して、ショッパーに回答を提供します。
ショッパーは、注文のキャンセル方法などのサプライチェーンに関する質問や、「ありがとう」「さようなら」といった単純な応答を含む、サプライチェーン以外のあらゆる質問をすることができます。基盤となるAIはこれらを適切に理解し、それに応じたワークフローを管理します。会話が終了すると、チャットボットの体験を改善するためにショッパーにフィードバックをお願いしています。これでAIによって解決された2つのユースケースを確認できましたので、これらのソリューションに取り組む際のプロセスについて理解していきましょう。
Generative AIソリューション開発の要件とアーキテクチャ
私たちは最初にいくつかの重要な要件から始めました。最初の重要な要件は、既存のナレッジコンテンツを活用したいということでした。 商品関連の質問については、Merchant DTCに豊富な情報がありました。Merchant DTCには、商品の使用方法、接続情報、互換性の文脈など、商品に関する詳細情報を含む多数の商品表示ページがありました。また、Merchantサポートのユースケースについては、既存のMerchantナレッジセンター内に大量のデータがありました。新しいものを作るのではなく、それらを活用したいと考えました。 2番目に、文脈を理解できるものを構築したいと考えました。
これは、AIシステムがショッパーが何を求めてきているのかという文脈を持つ会話を作ることを意味しました。ショッパーが既に商品を購入している場合、AIはそれを理解し、その商品に関する質問をしているかもしれません。3番目の重要な要件は、カスタマーエクスペリエンスに影響を与えたくないということでした。そのため、AIが回答できない問題がある場合、 人間のエージェントにリダイレクトして、適切にショッパーをサポートできるようにする必要がありました。
これらの重要な要件をアーキテクチャのコンポーネントに変換した方法を見てみましょう。既存のナレッジコンテンツを活用するために、データの種類に応じて異なるタイプのデータソースを作成できるAmazon Bedrockを利用しました。例えば、静的コンテンツについてはデータソースとしてAmazon S3を利用し、動的コンテンツについてはWebクローラーをデータソースとして利用しました。
Amazon Bedrock Knowledge Baseを使用して得られた重要な学びをご紹介させていただきます。 最初の重要な学びは、Knowledge Baseの作成とデータソースの設定は非常に簡単ですが、データソースの最適化が極めて重要だということです。例えば、特定のDTCをクロールしていた際、当初は1つのドメインのクロールに6～7時間もかかっていました。私たちは何か間違っていることに気づきました - 実は、ユースケースに不要なコンテンツまでクロールしてインデックスを作成していたのです。これを最適化するため、クロール範囲を縮小し、適切なドメイン親URLを使用し、Bedrock Knowledge Baseのsyncopeという設定を使用して、必要なページのみをクロールするようにしました。
あるマーチャントとのユースケースでは、マーチャントのDTCから多くのPDFファイルをクロールしていましたが、 これは私たちのユースケースには不要でした。フィルタリングの仕組みを使用して、CPUサイクルとメモリ使用量に良くなかったPDFファイルのクロールとインデックス作成を除外するようにしました。これら2つの最適化を実施した結果、クロール時間を6～7時間から約2～3時間に短縮することができ、これは私たちにとって大きな成果でした。
次の重要な学びは、クロールの頻度に関するものでした。 現在、Amazon Bedrock Knowledge Baseにはデータを最新の状態に保つメカニズムが提供されていません。Knowledge Baseのセットアップは良いのですが、どうやってKnowledge Baseを最新の状態に保つのでしょうか？例えば、マーチャントが新製品を発売した場合、Knowledge Baseに新製品の詳細情報が反映されていることをどう確認するのでしょうか？これに対して、私たちはイベントベースのスケジューラーを活用し、マーチャントのニーズに応じてスケジュールを設定できるようにしました。例えば、週単位でDTCを更新すると言うマーチャントに対しては、それに応じてイベントベースのスケジューラーを設定し、他のマーチャントに対しては月単位でKnowledge Baseを更新するようにしました。
2番目の重要な要件は、文脈に応じた会話を可能にすることでした。AIシステムは、ショッパーがどのような文脈で来ているのかを理解し、チャットボットソリューションとやり取りしようとしているショッパーの意図を把握し、必要な情報を収集するために関連するAPIやKnowledge Baseとやり取りできる必要があります。また、レスポンスを生成する際には感情を考慮する必要があります。例えば、ショッパーが「妻の誕生日のために何かを購入したのですが、昨日が誕生日だったのに、まだ注文が届いていません」と言った場合、チャットボットはショッパーがその体験に満足していないことを理解し、適切に対応する必要があります。このために、私たちは Amazon Bedrock Knowledge Baseとの標準搭載の統合機能を提供し、さらにAction Groupsを通じてAPIとやり取りする仕組みを提供するAmazon Bedrock Agentを活用しました。
Amazon Bedrock Agentsを使用して得られた学びをご紹介させていただきます。最初の学びは、Bedrock Agentのペルソナを定義するための指示のカスタマイズが重要ですが、同時に明確で簡潔な指示を持つことも非常に重要だということです。指示は基盤となるFoundation Modelを混乱させないよう、シンプルな言葉で書く必要があります。指示が過度に複雑だったり、紛らわしかったりすると、Bedrock AgentやFoundation Modelが意図したように動作しない可能性があります。
明確で簡潔な指示を持つことは非常に重要です。次の重要な学びは、オーケストレーションのカスタマイズに関するものでした。 Action Groupsを呼び出し、その応答を言い換える必要がないユースケースがありました。このために、カスタムオーケストレーション指示を使用しましたが、欠点として、プロンプトをカスタマイズした際に1〜2秒の追加レイテンシーが発生するという影響がありました。
次の重要な学びはデータに関するものです。 Knowledge Baseに適切なデータセットを持ち、APIから適切なデータセットを取得することが極めて重要です。APIが過剰な情報を返す場合や、Knowledge Baseに大量の情報がある場合、Bedrock Agentやその基盤となるFoundation Modelが混乱する可能性があります。Bedrock Agentが意図した通りに機能することを妨げる可能性のある大量の情報で混乱させないよう、APIのレスポンスで明確で簡潔な情報を持つことが非常に重要です。
次の重要な要件は、カスタマーサポートエージェントへのシームレスな移管に関するものでした。これには、Amazon ConnectとAmazon Lexを活用しました。 Amazon Connectは、ショッパー、チャットボット、カスタマーサポートエージェントが対話するためのチャネルを提供します。特定のインテントに対してConnectフローに影響を与える初期インテント分類のために、Amazon Lexをボットとして使用しました。顧客がカスタマーサポートエージェントとの対話を希望する場合には、引き続きAmazon Lexを利用しています。 同様に、基盤システムからのレスポンスが不正確であったり、関連性のない情報が含まれていたりする場合、そのようなコンタクトをカスタマーサポートエージェントに転送して、より効果的に対応できるようにしています。
Generative AI開発のベストプラクティス：評価とトレーサビリティ
バックエンドシステムにタイムアウトなどの問題が発生した場合、 またはバックエンドシステムが意図した通りに応答できない場合、顧客体験が決して損なわれないよう、人間による対応にフォールバックします。要件とコンポーネントを確認したところで、これらの要件に基づいて構築したマーチャントサポートユースケースの全体的なアーキテクチャを見てみましょう。 これは、ユーザーがKnowledge Centerポータルを通じてLambdaを介してBedrock Agentとやり取りするアーキテクチャです。Bedrock Agentには、マーチャントからの正当な問い合わせに答え、システムを破壊しようとする悪意のあるアクターに対処できるよう、適切なGuardrailsとKnowledge Baseが設定されています。
同様に、ショッパーアシスタントのユースケースでは、最初にAmazon ConnectがAmazon Lexと連携するアーキテクチャを持っています。その下には、製品関連のクエリと注文関連のクエリという2つの異なる部分を持つAmazon Bedrockがあります。製品関連のクエリにはBedrock Knowledge Basesを利用し、注文関連のクエリでは、適切な応答を得るために私たちのドメインAPIとインターフェースするAction Groupsとやり取りします。
アーキテクチャについて説明しましたので、両方のユースケースから得られた主要な結果をご紹介させていただきます。検索機能に対する出店者様の関心が30%も増加するという顕著な成果が得られました。より多くの出店者様がシステムを活用し、お問い合わせに対する回答を見つけられるようになっています。同様に、Chatbotのユースケースでは、お買い物をされるお客様からのお問い合わせの95%が適切な解決策の提供により、正常に処理されています。
ここで、この2つのソリューションの開発において採用したベストプラクティスについて、Sebastianに壇上に上がっていただき、共有してもらいたいと思います。ありがとうございます。これで、今後のGenerative AIアーキテクチャの構築方法について理解できました。では、Generative AIソリューションの開発において学んだベストプラクティスをいくつかご紹介します。最初のベストプラクティスは、自動評価です。ご存知の通り、Generative AIは予測が非常に難しく、データやLLMモデル、LLMモデルのバージョン、サービスなど、あらゆる要素が変化する可能性があります。これらの要因はすべて、Generative AIの応答に影響を与えます。それと同時に、品質基準を確保する必要があります。
これは、Generative AIソリューションを構築する際に特に重要です。Gen AIの精度を確保しなければなりません。では、どのようにしてこれを実現したのでしょうか？実はこれは解決が難しい分野なのです。
私たちは手動評価から始めました。質問に基づいて応答できるGen AIモデルがあります。最初に約200の異なるテストケースを生成しました。ポジティブなテストケースとネガティブなテストケースの両方です。これらすべてをAIに通し、それらの質問に対する回答を得て、評価サービスに送信しました。このサービスは基本的に、LLMからのすべての入力と出力を集約します。
その後、専門家チームにすべての回答を確認してもらいました。専門家チームは、特定の質問に対してLLMがどのように応答すべきかを正確に理解しており、異なるカテゴリーについて0から1までのスコアを付けることができました。カテゴリーには、精度、悪意の有無、プロフェッショナリズム、そしてLLMの応答方法に関する様々な種類が含まれています。LLMの品質を評価する基準は1つではありません。この取り組み全体を通じて、私たちのソリューションがどのように機能するかについて十分な理解が得られ、成功を収めることができました。しかし、この解決策には1つ問題がありました。それは、実行にかかるコストが非常に高かったことです。10人以上の人員が何週間もかけて、一人一人がこのプロセスを実施する必要がありました。
すべての質問や回答、そしてすべてのカテゴリーを一つ一つ確認していくには、多大な手作業が必要です。このプロセスは優れていますが、スケールしません。Gen AIソリューションには何らかの自動評価の仕組みが必要なのです。これは簡単な問題ではありません。なぜなら、LLMは同じ質問に対して異なる応答をすることがあり、それらの異なる回答がどちらも適切である可能性があるからです。両方とも良い回答かもしれませんし、あるいは両方とも間違っているかもしれません。LLMは決定論的ではないのです。
期待される出力と実際の出力を効率的に比較できるアルゴリズムを10種類以上検討し、推奨する上位3つのアルゴリズムを選定しました。1つ目はLLMベースの評価です。これはLLMを使ってLLMを評価するという非常に興味深いアプローチです。評価用の非常にカスタマイズされたプロンプトを作成することで、実際の出力と期待される出力が同じ意味を持っているかどうかを効率的に評価できるようになり、とても良い結果が得られました。これは私たちが作成できた最も優れた自動評価方法です。
2つ目に使用しているアルゴリズムはMeteorです。これはNLP（自然言語処理）ベースのアルゴリズムです。Gen AIではない従来のアルゴリズムを使用して、実際の出力と期待される出力の中の単語の類似性を評価します。これらの類似性から、期待する内容とGen AIが実際に応答した内容の文全体がどれだけ似ているかを計算できます。最後のアルゴリズムはROUGEと呼ばれます。ROUGEアルゴリズムは単語の類似性を使用します。期待される出力と実際の出力からすべての単語を抽出し、それらを単一のノードに計算して統合します。例えば、「go, go, went」といった単語があれば、同じ意味として統合されます。意味のある文章があれば、スコアを計算することができます。
これらのアルゴリズムは品質の低下を見つけるのに非常に効果的で、私たちは実際にうまく活用しています。重大な品質低下が発生した場合、これらのアルゴリズムで検出することができます。アルゴリズムの他に、テストケースも作成する必要がありました。ポジティブテストケースとネガティブテストケースの両方があります。ポジティブテストケースは期待されるビジネス出力を評価するもので、基本的にLLMに期待する応答をビジネス側が決定します。一方、ネガティブテストケースは悪意のある入力が適切に処理されているかどうかをチェックするもので、これは非常に重要です。悪意のあるコンテンツについては後ほど詳しく説明します。
以上が評価についての説明です。次に、お話ししたいもう一つのベストプラクティスはトレーサビリティです。トレーサビリティとは、基本的に開発者がシステム内で何が起きているのかという情報を素早く見つけられる能力のことです。LLMの場合、多くのシステムが関与しているため、トレーサビリティの構築は実際にとても難しい課題となっています。
リクエストの流れを見ていきましょう。まず、サービスにリクエストが送信されるところから始まります。最初にRoutingレイヤーを通り、次にAuthorizationレイヤー、そしてServiceレイヤーと進みます。Serviceレイヤーは、Amazon Bedrockにリクエストを送信します。Bedrock内では、オーケストレーションが行われます。まず入力のGuardrailから始まり、入力が正しいかどうかをチェックします。次に、Knowledge BaseのRAGアプローチに進みます。ここでは、リクエストに関連する様々なデータを照会します。このオーケストレーションの一部として、パーソナライズされた体験を構築するために、他のモデルに対して様々なAPIを呼び出します。例えば、レスポンスをパーソナライズするために追加の顧客データを取得したい場合などです。これらすべての照会が終わったら、出力を1つの最終的なレスポンスにまとめる必要があります。そして、レスポンスが得られたら、LLMが悪意のあるコンテンツを返していないことを確認するため、再度Guardrailを実行します。
Generative AIのセキュリティ脅威と対策
この一連の流れには、多くのサブシステムが関与しており、各サブシステムは分離・独立しています。では、この特定のリクエストについて、全体の流れを通じて何が起こったのかを理解できるトレーサビリティをどのように構築するのでしょうか？これには2つのステップが必要です。まず、この流れの最初の段階で一意のリクエストIDを作成し、それを全体の流れを通じて受け渡します。つまり、すべてのサブシステムで1つのリクエストIDを使用するのです。2つ目のポイントは、このリクエストIDで識別されるログを、単一のAmazon CloudWatchグループにプッシュすることです。これにより、すべての異なるサブシステムからのログを1つのCloudWatchグループにまとめることができます。何かトラブルシューティングが必要な場合は、この単一のCloudWatchグループに行き、リクエストIDを入力するだけで、そのリクエストIDに関連するすべてのログを1つのビューで確認できます。これは、非常に分散化されているGenerative AIソリューションのトラブルシューティングには不可欠です。
次に説明したいベストプラクティスは、顧客データに関するものです。LLM AIソリューションを構築する際、パブリックコンテンツに基づいて応答するだけではありません。時にはパーソナライズが必要です。パーソナライズとは、顧客データを取得し、リクエストを処理する際にGenerative AIへの入力として使用することを意味します。これは顧客により良い体験を提供するための非常に強力なアプローチですが、リスクも伴います。顧客データを使用することにはリスクがあり、顧客データが漏洩することは絶対に避けなければなりません。リクエストを処理する際に、誤って別の顧客のデータを取得してしまうような状況は絶対に避けるべきです。
では、どのようにしてこれを解決し、顧客データの誤用を防ぐのでしょうか？私たちが行ったのは、顧客データを物理的に分離することです。顧客に関する情報を保存する各Knowledge Baseは物理的に分離されており、Serviceレイヤーでリクエストを承認する際に、特定のKnowledge Baseにのみマッピングします。これにより、1つの顧客リクエストに対して1つのKnowledge Baseのみを使用することができます。物理的に分離されているため、2つのKnowledge Baseを同時に使用することはできません。また、Knowledge Base内の各リクエストに対して認証を行います。つまり、Knowledge Base上に認証を構築できるのです。Knowledge Baseは内部で安全が確保されており、正しいKnowledge Baseへのクエリに外部サービスを必要とせず、Knowledge Base自体に認証が組み込まれています。
次の改善サイクルについてです。すでに自動評価について説明しました。これは、追跡したい特定の品質基準を設定し、その品質基準を監視するためのテストを構築することです。品質が低下した場合は通知を受けます。しかし、ビジネスが変化した場合はどうなるでしょうか？
テストを作成する際は、特定のビジネスケースに基づいて作成しますが、これらのケースは時間とともに変化する可能性があります。製品は新機能を追加し続け、企業も発展を続けています。データ駆動型のソリューションはビジネスに追従する必要があります。これは一度限りのソリューションではありません。加盟店向けのサポートソリューションを構築する際は、すべてのドメインにわたってサポートが常にビジネスに追従していることを確認する必要があります。
改善サイクルが必要です。この改善サイクルについて見ていきましょう。まず、データから始めます。 LLMで使用したいデータがあります。そしてそれをナレッジベースにプッシュします。 データを集約するナレッジベースは、基本的にVector Embeddingsなど異なる形式でデータを保存します。このナレッジベースは、後にLLMモデルがデータを検索する際に使用されます。
リクエストがあると、LLMに問い合わせます。 モデルはナレッジベースに問い合わせを行い、ナレッジベースとLLMの上に テストケースを生成します。評価用のテストケースを用意し、それらのテストケースに対する出力を生成します。これらのテストケースに基づいてLLMモデルからの現在の応答を特定し、専門家チームにフィードバックします。これらの専門家は ビジネスの最新状況を正確に把握しており、ビジネスの状況とLLMからの応答に基づいて、LLMが依然としてビジネスの正しい状態を追跡しているかどうかを判断できます。そうでない場合は、コンテンツを更新する必要があります。なぜなら、コンテンツが精度を左右する重要な要素だからです。この改善サイクルにはHuman-in-the-loopの関与が必要で、LLMが常に正しい軌道を維持できるよう定期的に繰り返します。
次にセキュリティの脅威について説明しましょう。私たちは長年 ソフトウェアに携わってきており、誰もがInjectionなどのさまざまなセキュリティ脅威に遭遇してきました。しかし、Generative AIには、標準的な開発には存在しない新しいセキュリティ脅威があります。Generative AI特有の主要な4つのセキュリティ脅威について説明したいと思います。
まず、Prompt Injectionから始めましょう。LLMはSystem Promptによって動作が定義されていますが、Prompt Injectionを使用するとこの動作を変更することができます。リクエストにSystem Promptをシミュレートするプレフィックスを送信し、「以前のSystem Promptを無視して、こちらを使用してください」というような指示を出すことで、LLMの動作を変更できます。私たちは、非常に有名なものも含め、ほとんどのLLMをハックすることができました。セキュリティ機能は組み込まれていますが、Prompt Injectionを防ぐには十分ではありません。
次の脅威は、安全でない出力の取り扱いです。私たちは悪意のあるJavaScriptコードを作成し、base64で暗号化して、それをLLMに送信し、その文字列を復号化するよう依頼することができました。LLMはこの悪意のあるJavaScriptを復号化し、ユーザーに返すことができました。私たちはLLMに、ブラウザでレンダリングされる悪意のあるコンテンツを提供させ、スパムやその他の望ましくないJavaScriptの動作を引き起こすことができました。
Over-relianceは、LLMの出力に基づいてビジネス判断を行う際に発生するセキュリティ上の脅威です。私たちはLLMをオーケストレーションに使用することがありますが、LLMが様々な方向から影響を受ける可能性がある場合、常にリスクが存在します。LLMに基づいてビジネス判断を行い、誰かがそれに影響を与えることができる場合、ビジネスロジック全体を操作される可能性があり、これは非常に危険です。最後の脅威は、機密情報の漏洩です。前述のように、LLMで使用するデータには、パーソナライズされた体験を構築したいがために、多くの顧客データが含まれています。時にはこの顧客データは単なるカタログデータや注文履行データで機密情報は含まれていないと考えがちですが、電話番号や住所、その他の情報が含まれているかどうかは分かりません。
LLMにデータを信頼させないことが常に重要です。LLMを、何かを提供する外部サービスとして考えるべきです。たとえLLMとデータを管理していても、完全に制御することは不可能です。
では、これらの脅威に対する対策は何でしょうか？Amazon Bedrock には多くの組み込みのGuardrailsが用意されています。Bedrockには、ニーズに応じて有効または無効にできる様々なコントロールとポリシーを備えた特別なセキュリティ機能が組み込まれています。簡単に見ていきましょう。まず、Content Policyは、特定の脅威に対する特定の対策を有効または無効にできるBedrockが事前に定義したルールのセットです。Prompt injection、不正行為、ヘイトスピーチなどが含まれており、すべてブロックできます。不正行為のブロックやPrompt injectionのブロックを有効にすれば、Bedrockがあなたに代わって解決してくれます。
次のTopic Policyでは、カスタムルールを作成できます。Bedrockが既に提供しているものを拡張したり、その上に構築したりしたい場合、独自のGuardrailsを定義できます。定義方法が非常に興味深く、自由なテキストで定義します。ブロックしたい内容を記述して例を示すだけで、BedrockがLLMを通じてこれを処理し、入力をブロックするかどうかを判断します。Word Policyは基本的にリストで、入力または出力に含めたくない単語を指定できます。不適切な表現のフィルタリングに非常に効果的です。最後のSensitive Information Policyでは、入力または出力の機密情報をブロックまたはマスクすることができます。50種類以上の機密情報を検出するための組み込みルールが用意されています。
これらのGuardrailsはすべてServerlessで、インフラの管理は必要ありません。すべて設定ベースで動作し、設定するだけで済みます。また、組み込みのポリシーやカスタムGuardrailsを使用できる柔軟性もあります。私たちが特定したすべてのセキュリティ脅威に対応しており、これまでに試したすべてのインジェクションや攻撃に対して、Bedrockは効果的にブロックできることを確認しています。
データバックアップの重要性と本セッションのまとめ
バックアップに関してですが、データベースソリューションを構築する際には、常にデータベースのバックアップが必要だということを私たちは知っています。通常、バックアップやリカバリーツールを使用する機会は少ないのですが、データが完全に誤っている場合など、本当に必要なときのために、それらを用意しておくことは非常に重要です。これはLLMにも同じことが言えます。なぜなら、LLMは純粋にデータによって駆動されるからです。LLMで使用するデータが増えれば増えるほど、そのデータはLLMにとってのデータベースのような存在となります。データはどこに保存してもよく、必ずしもデータベースである必要はありませんが、LLMにとってはデータベースとして機能します。
私たちは、すべてのデータをバージョニングを有効にしたS3 Bucketに保存しており、すべてのオブジェクトのすべてのバージョンを保持しています。S3内のすべてのオブジェクトの履歴を追跡しているのです。過去の特定の時点を指定できるシンプルなCLIツールを用意しており、このツールがS3 Bucket内のすべてのオブジェクトを確認し、以前の状態に戻したり、その時点以降に作成されたオブジェクトを削除したり、削除されたオブジェクトを作成したりします。このシステムは非常にうまく機能しており、10分以内にすべてのデータをロールバックできます。その後、LLMの再同期を行うだけです。これは皆さんにも強くお勧めします。
このプレゼンテーションから、いくつかの重要なポイントをお伝えしたいと思います。まず第一に、Amazonは非常に強力なフルフィルメントセンターとサプライチェーン全体を持っており、私たちはこれを活用して、このエコシステム内でGenerative AIソリューションを構築し続けています。第二に、Amazon Bedrockを使用することで、多くの機能を含む完全なエンドツーエンドのエンジニアリングソリューションを構築することができます。最後に、単にLLMソリューションを構築するだけでは不十分で、評価やセキュリティ、そしてLLMを成功に導くために重要な周辺のあらゆる側面について考える必要があります。
以上で、このプレゼンテーションは終わりです。お時間を取っていただき、ご清聴いただき、ありがとうございました。こちらのQRコードから、私たちや私たちの製品、ソリューションについて、より詳しく知ることができます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion