re:Invent 2023: Buy with PrimeとAmazon Bedrockで実現する次世代ショッピングアシスタント
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Buy with Prime: Exploring possibilities with Amazon Bedrock (BWP303)
この動画では、Buy with PrimeとAmazon Bedrockを組み合わせた革新的なショッピングアシスタントの構築方法を紹介します。Agents for Amazon Bedrockを活用し、Buy with Prime APIと連携させることで、自然言語での商品検索や詳細情報の取得が可能になります。GraphQLを用いたデータ取得の柔軟性や、トレースイベントを利用したユーザー体験の向上など、実践的なテクニックも解説。eコマースの未来を垣間見ることができる、刺激的な内容です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Buy with Prime: Amazon Bedrockの可能性を探るセッションの開始
みなさん、こんにちは。質問から始めさせていただきます。お気に入りのブランドでのショッピング体験をもっと簡単にしたいと思う方は何人いらっしゃいますか？手を挙げてください。素晴らしい、同じ考えのようですね。私はBuy with PrimeのSenior Solutions ArchitectのZubeen Sahajwaniです。本日のセッション「Buy with Prime: Amazon Bedrockの可能性を探る」へようこそ。今日のセッションに入る前に、私のチームをご紹介させてください。
Jonathan Kimもいます。 彼もBuy with PrimeのSenior Solutions Architectで同僚です。AWSサービスを使用したソリューション構築の専門家として知られています。Jonathan？
みなさん、こんにちは。Buy with PrimeチームのSenior Solutions ArchitectのJonathan Kimです。このチームに加わる前は、Amazon Web Servicesで3年半働いていました。みなさんにお会いできて嬉しく思います。Buy with PrimeとAmazon Bedrockを使用してパーソナルショッピングアシスタントを提供する方法をお見せできることを楽しみにしています。お会いできて光栄です。
ありがとう、Jonathan。そして、Amazon BedrockのPrincipal Software EngineerであるJohn Bakerも参加しています。Johnは、Generative AIやfoundation modelsなどの最先端技術に関する豊富な経験を持っています。Johnから直接お話を伺いましょう。
みなさん、こんにちは。今日ここにいられることを光栄に思います。このショッピングデモを紹介し、BedrockとFoundation Modelsで自動化するために私たちが構築したものをシェアできることを楽しみにしています。実は、私はAmazonで10年働いています。Primeチームから始まったので、彼らと協力して私たちが構築したものを紹介できるのは素晴らしい機会です。
Buy with PrimeとAmazon Bedrockを活用したショッピングアシスタントの概要
ありがとうございます、John。これから、Buy with Prime APIとAmazon Bedrockの興味深い側面について一緒に探っていきましょう。そう言いつつ、今日の議題は刺激的な内容で満載です。まず、Buy with Primeとその強力なAPIの概要から始めます。次に、Buy with Prime APIとGenerative AI搭載のAWSマネージドサービスであるAmazon Bedrock用Agentsを使用したショッピングアシスタントのコンセプトを探ります。セッションの最後には、GenAIベースのソリューション構築に興味のある方々に役立つ貴重なベストプラクティスについてお話しします。
本題に入る前に、私たちのユースケースの概要を少しお話しさせてください。10年前の自分に、将来、数千もの商品の中から完璧な一品を簡単に見つけられるようになると言ったらどうでしょう。しかも、商品だけでなく、自然言語を使って評価や購入に必要な他の商品情報にもアクセスできるのです。さらに興味深いのは、Buy with Primeを使ってチェックアウトすれば、最短1日で配送され、簡単な配達と無料返品も可能になるということです。
「これはどうやって実現したの？」と思われるかもしれません。そこで私たちは、Amazon Bedrockを使用してショッピングアシスタントを作成した場合のコンセプトをお見せしたいと思います。では、Amazon BedrockとBuy with Prime APIを使用してこのデモンストレーション用に作成したショッピングアシスタントの全体像を見てみましょう。Amazon Bedrockは、すぐに使えるGenAI機能を提供し、この統合の重要な基盤を確立します。一方、Buy with Prime APIは、その可能性を拡張するための重要な手段として機能します。これらのAPIは、ショッピング体験を向上させるために活用できるデータや機能へのアクセスを提供します。
開発者として、これらのコンポーネントを組み合わせることで、ショッピングアシスタントのコンセプトの基盤が作られます。これは、GraphQLのような最新のAPI構造とAmazon Bedrockを使用したGenerative AIを使って構築した場合に可能になることを示しています。この概要を聞いて、さらに疑問が湧いてきたのではないでしょうか。幸運なことに、これからこの統合をどのように作成したかを詳しく説明していきます。
Buy with Primeの概要とAPIの機能
まずはBuy with Primeから始めましょう。Buy with Primeは、出店者が自社サイトでPrimeのショッピング特典を提供することで、eコマースビジネスを加速させることができるサービスです。皆さんの中には、お気に入りのオンラインストアで買い物をする際にBuy with Primeを目にした方もいらっしゃるかもしれません。
これにより、商人は Prime の信頼性、迅速で無料の配送の約束、そして何百万もの買い物客に信頼されているチェックアウトプロセスを活用して、顧客を獲得することができます。
小売業者がオンラインストアを立ち上げることを想像してみてください。特に商品数が限られている場合、一見簡単そうに見えます。しかし、カタログが拡大するにつれ、すぐに課題が増え、困難になります。競争の激しいオンライン市場で成功するには、商人は商品カタログの管理だけでなく、ビジネスの複数の領域に取り組む必要があります。顧客の期待に応えるには、優れた注文管理と配送が必要です。そこで Buy with Prime の出番となります。サイトに Buy with Prime を追加することで、商人は Buy with Prime 注文の迅速で無料の配送で顧客を獲得でき、一方で Amazon が支払い処理、保管、梱包、配送を担当します。
Buy with Prime の統合についてさらに掘り下げていくと、Buy with Prime API の機能について詳しく見ていきましょう。これらの API は、開発者が独自のソリューションを作成するための基本的な構成要素と考えてください。これにより、あなたの特定の目標やニーズに合わせて統合をデザインする自由が得られます。これらの API はタスクの自動化とシームレスな統合を実現し、リアルタイムの更新を可能にします。
Buy with Prime ウィジェットをウェブサイトにインストールし、想定通りに機能している商人として、さらに一歩進んでみたいと思うかもしれません。商品のメタデータをカスタマイズしたり、顧客の注文を追跡するために注文ステータスをほぼリアルタイムで同期したいと考えるかもしれません。そこで Buy with Prime API が非常に価値を発揮し、ビジネスにシームレスな統合を作成するために必要なすべてのツールとドキュメントを提供します。
要約すると、一部のビジネスは Buy with Prime API を使用して、自社のビジネスに独自の統合を作成することにさらに深く取り組むかもしれません。今日のセッションでは多くの内容を扱うので、シンプルに保ち、デモで広く使用した Product API に焦点を当てます。他の Buy with Prime API についてもっと学びたい方のために、このセッションの最後に QR コードをご用意しています。
Product APIの活用とeコマースの進化
Product APIを使用すると、製品の管理、製品メタデータのカスタマイズ、そして在庫状況や価格に関するほぼリアルタイムの更新を維持することができます。Product APIには複数の潜在的なユースケースがありますが、そのうちの1つを簡単に説明します。例えば、自社のウェブサイトから直接Buy with Primeを提供する製品を選択したい場合があります。Buy with Prime Product APIを利用することで、自社のカタログとBuy with Prime製品カタログの間でほぼリアルタイムの同期を作成し、自社のウェブサイトから直接製品にBuy with Primeを提供することができます。
これらのAPIは幅広い機会を開き、テクノロジー主導の時代において基本的な役割を果たしています。テクノロジーが急速に進歩するにつれて、私たちのテクノロジーの利用と依存度も高まっています。例えば、靴を見てみましょう。スポーツ、カジュアル、ラグジュアリーなど、さまざまな目的に合わせて設計された幅広い種類の靴があります。各カテゴリーには数え切れないほどのオプションがあり、自分のスタイルやニーズに基づいて豊富な選択肢があります。
各カテゴリーで利用可能なオプションの豊富さには驚かされます。テクノロジーは製品をこれまで以上に身近なものにしただけでなく、利便性の真の意味を再定義しました。文字通り、ウェアラブル、TV、ソーシャルメディア、または携帯電話を使って、古いガレージドアの部品のような珍しいアイテムから日用品まで、オンラインで何でも見つけることができます。事実上、すべてのものが指先で利用でき、玄関先まで配達されます。
オンラインショッピングの課題：ガレージドアオープナーの事例から
ガレージドアと言えば、皆さんも共感できるかもしれない最近の経験を共有したいと思います。ご覧の画像は私のガレージドアオープナーです。下から撮影しました。
なぜなら、私のガレージドアオープナーはカメラを少し恥ずかしがるので、その気持ちを傷つけたくなかったからです。実際、私のガレージドアオープナーはかなり古く、20〜25年ほど経っています。ある日、動かなくなってしまいました。これはよくあることです。技術者に相談したところ、部品が見つからないという理由で高額な見積もりを出されました。システム全体の交換を提案されました。私はeコマースに携わっているので、自分でその部品を探してみることにしました。
部品を見つけた後でさえ、それが正しいものかどうか完全には確信が持てませんでした。自分のモデルと年式に合うかどうか不安でした。徹底的に調べましたが、助けになる情報は見つかりませんでした。そこで、思い切ってその部品を購入することにしました。幸運にも、ぴったり合いました。この後すぐに、なぜこのガレージドアの話をしたのか分かります。
選択肢が無数にあり、意思決定を助けるツールがたくさんあるのは確かにありがたいことです。しかし、これほど多くの選択肢やツールがあると、誰でも簡単に圧倒されてしまいます。製品に関する十分な情報がないために、フラストレーションを感じてカートに入れたままにしてしまうことも珍しくありません。先ほどのガレージドアの話に戻りますが、ガレージドアオープナーを修理するための特定の部品を探していた時、正しい製品を手に入れるには、その部品に関する重要な知識が必要だと気づきました。
その製品をどこで探せばいいのか、例えば販売サイトなどを知ることが重要でした。同様に重要だったのは、関連する結果を得るための正確なキーワードを知ることでした。部品を購入する際の判断に影響を与えたかもしれない別の要因は、適切な製品情報を見つけることでした。私の場合とは異なり、互換性やその他の製品関連情報を見つけるのに苦労しました。これらの要素は、特に無数の選択肢に囲まれているこのデジタル時代において、探しているものを見つけるために非常に重要です。
昔のように実店舗に入っていくのとは違います。当時は、キーワードを使う必要はありませんでした。その頃は、フレンドリーな店員さんが適切な製品を見つけるのを手伝ってくれました。適切な製品を見つけるだけでなく、あらゆる質問に答え、自信を持って購入するために必要な情報を提供してくれました。今日、私たちは2つの異なる世界にいます。フレンドリーな店員が選択をガイドしてくれた昔の世界と、便利さと無数の選択肢がクリック一つで手に入る今日のデジタル時代の世界です。
豊富なツールと様々な選択肢により、多くの課題が解決されました。しかし、可能性の広大さは時として迷路を歩いているような感覚を与えることがあります。これは根本的な疑問につながります：どうすれば買い物客が十分な情報を得た上で決定できるよう手助けできるでしょうか？おそらく、彼らが探している製品へと導く手助けをすることで可能になるでしょう。では、AWS servicesとchatbotの構築に関する社内エキスパートであるJonathanの話を聞いてみましょう。彼が、買い物を魅力的にし、価値ある洞察を提供する方法について説明してくれます。
Agents for Amazon Bedrockを活用したチャットボットの構築
Jonathan: はい、ありがとうございます、Zubeen。また戻ってこられて嬉しいです。 Zubeenが説明したように、私たちはオンラインで幅広い製品を購入でき、さまざまなオプションを通じて個々のニーズに合わせたカスタマイズ製品を購入することもできます。 しかし、豊富な選択肢があるため、ショッピングは少し圧倒されることがあります。多くの製品、選択肢、イベント、プロモーションがあります。良い製品を良い価格で購入するチャンスを逃したくありません。そして、配送の問題もあります。この製品をできるだけ早く手に入れたいですね。また、サイズや色を変更したい場合に備えて、返品オプションも確認する必要があります。何が起こるかわかりませんからね。選択肢が多いことは買い物客にとって素晴らしいことですが、プロセスをより複雑にすることもあります。
通常、多くの選択肢があることは買い物客にとって素晴らしいことです。しかし、Zubeenがしたように、欲しいものを正確に見つけるには調査が必要な場合があります。でも、オンラインショッピングモールで、実店舗での買い物アシスタント体験をどのように得られるでしょうか？例えば、今週末ビーチに行くので靴が必要だとします。実店舗に行って欲しいものが見つからない場合、買い物アシスタントと目を合わせて「今週末ビーチに行くんですが、どんな靴が必要でしょうか？」と言えます。会話が始まり、アシスタントは特定のセクションに案内してくれたり、試着する製品を持ってきてくれたりします。
オンラインの世界でこのような買い物アシスタント体験をどのように得られるでしょうか？チャットボットがこの対面体験を提供するのに役立つかもしれません。 では、この対面買い物アシスタント体験を提供するチャットボットの構築方法について詳しく見ていきましょう。 開発者の観点から見ると、チャットボットは買い物アシスタントを提供するのに非常に適したツールです。しかし、チャットボットを構築する最初のステップは何でしょうか？買い物客の質問に答えるために、すべての意図をチャットボットに入力することを考えるかもしれません。しかし、これは困難な作業であり、すべての買い物客の質問に効果的に答えるには不十分です。
靴を探しているとしましょう。単にその質問をサポートするだけでは不十分です。「どんな種類の靴が必要ですか？」や「どのサイズや色がお好みですか？」といったフォローアップの質問をする必要があります。したがって、チャットボットは買い物客が必要とするものを正確に提供するために質問し、買い物客とチャットボットの間の会話をリードする必要があります。 チャットボットは会話をリードするだけでなく、行動を起こす必要もあります。例えば、サイズ11の青い靴が必要な場合、アシスタントは「在庫を確認して、サイズ11の靴が利用可能かどうか見てみます」と言うかもしれません。これは、チャットボットが他のシステムと通信する必要があることを意味します。
チャットボットの観点から見ると、これはシステムがAPIなどの他のシステムと相互作用するためのインターフェースを提供する必要があることを意味します。この場合、Zubeenが説明したように、Buy with PrimeはAPI経由で機能を提供しているので、チャットボットはBuy with Prime APIを呼び出して製品情報を収集できます。効果的なチャットボットを構築するには、2つのことが必要です。まず、チャットボットはGenerative AI技術を使用して会話をリードする必要があります。次に、チャットボットは会話に基づいて行動を起こす必要があります。
Amazon Bedrockエージェントの仕組みと動作原理
シンプルなチャットボットを作るだけでも大変な作業になる可能性があります。そこで、Agents for Amazon Bedrockをご紹介したいと思います。これは完全マネージド型のサービスで、プロンプトや指示を使ってエージェントを設定できます。エージェントは会話と基盤モデルの間のやり取りを調整します。この会話に基づいて、エージェントはAPIを呼び出してアクションを実行します。では、エージェントを設定する最初のステップは何でしょうか？それは指示を与えることです。「買い物客の質問に答え、それに基づいて商品情報を提供すること」と指示します。
そうすると、エージェントは会話を作成し、買い物客をサポートするためのアクションを取ります。
説明よりも実際の動作を見る方が良いですよね？ここに、様々な種類の靴を販売しているシンプルな靴店があります。一部の商品はBuy with Primeで提供されています。Primeバッジが表示されているのがわかりますね。また、チャットボットも用意されています。バックエンド側では、このチャットボットはAmazon Bedrockをベースにしています。つまり、Amazon BedrockがBuy with Prime APIを呼び出しているのです。
ここに商品リストがあるのがわかります。Buy with Prime product APIを呼び出しており、APIを使って商品情報を設定したり変更したりすることもできます。Agents for Amazon BedrockがBuy with Prime APIを呼び出します。例えば、ビーチ旅行用の靴を探しているとしましょう。「今週末ビーチに行くんですが、どんな靴が必要でしょうか？」と尋ねると、エージェントはBuy with Prime APIを呼び出し、それに基づいてビーチウォーターシューズ、スイムウォーターシューズ、スポーツシューズなどをいくつか推薦します。
次に条件を追加して、「サイズ11で評価の星が高いものを探しています」と言います。エージェントはこの会話を処理し、Buy with Prime APIを呼び出して、それに基づいて特定の商品をいくつか推薦します。さらに詳しい商品情報を尋ねると、チャットボットは商品詳細ページに案内してくれます。Buy with Primeボタンが表示されているのがわかりますね。Primeメンバーであれば、スムーズにこの商品を購入し、チェックアウトを完了して、2日以内に商品を受け取ることができます。
それでは、仕組みについてより詳しく見ていきましょう。ショッパーは「このような商品が欲しい」といった質問をします。内部的には、チャットボットがこれらのコメントをAgentのBedrockに入力します。Agentは会話とfoundation model、そして私たちのプロンプトの間でオーケストレーションを行います。私たちはショッパーをサポートするための指示を入力しただけです。この会話に基づいて、AgentはLambda関数をトリガーしてアクションを起こします。この場合、LambdaはBuy with Prime APIを呼び出して商品情報を取得します。
Lambda関数内では、Buy with Prime APIを呼び出します。ここで注目したいのは、Buy with Prime APIがGraphQLで提供されているということです。GraphQLはクエリ言語なので、Agent側で必要なものを選択できます。柔軟な方法でデータをクエリできるのです。その後、結果が得られます。
Buy with Prime APIについてもう少し詳しく見ていきましょう。先ほど言ったように、Buy with Prime APIはGraphQLエンドポイントで提供されているので、クエリする内容を選択できます。つまり、AgentはBuy with Prime Product APIからすべてのデータを必要としないということです。タイトル、説明、星の数などだけが必要になります。ポストペイロードでデータを選択し、必要なデータを取得できます。このように、Buy with Prime APIを柔軟な方法で呼び出し、データを選択できるのです。
Amazon Bedrockエージェントの設定と実装プロセス
Amazon Bedrockがどのように機能するのか気になっているかもしれませんね。そこで、Johnに来てもらって、その仕組みを見てみましょう。ありがとう、Jonathan。本当に感謝しています。Agentの詳細に入る前に、少し立ち戻ってみましょう。まず、Amazon Bedrockとは何かについて話しましょう。
Bedrockは完全マネージド型サービスで、Generative AIアプリケーションの構築とスケーリングに使用できます。これには、Agents for Bedrockが行うワークフローのオーケストレーションも含まれます。APIといくつかの簡単な指示を提供すれば、ユーザーの入力に応じてそれらのAPIをオーケストレーションします。
では、どのようにしてエージェントを作成するのでしょうか？ Amazon Bedrockのランディングページに行き、Agentsを選択すると、Create Agentというボタンが表示されます。それを選択すると、詳細情報の入力を求められます。エージェント名と説明を入力します。これらは文書化のためのものであり、精度には影響しませんが、各エージェント名は一意である必要があります。
次の画面は精度にとって非常に重要です。ここでモデルを選択しますが、ご覧のように、エージェントはAnthropicファミリーのモデルをサポートしています。Amazon Titanモデルもまもなく追加される予定で、時間とともにさらに多くのモデルベンダーを追加していくにつれて、この選択肢は拡大していくでしょう。今回のユースケースでは、Claude V2を選択しましたが、Claude Instant V1や近日公開予定のClaude 2.1もサポートしています。
この画面での最後のステップは、エージェントに指示を与えることです。これは非常に重要で、ここでエージェントにペルソナを与えます。今回のユースケースでは、顧客とやり取りするチャットエージェントを構築しているので、丁寧でフレンドリーなペルソナを持たせたいと考えています。そこで、「あなたはフレンドリーなショッピングアシスタントです。買い物客の質問に答えてください」と指示します。これらの指示は、大規模言語モデルに送られる各プロンプトに含まれ、自然言語の回答を生成する際にその口調に偏向させます。特にチャットインターフェースを構築する場合は、必ずペルソナを設定することをお勧めします。
次のステップは、特定のアクションやツールを追加することです。これらをAction groupsと呼んでいますが、その理由はすぐにわかります。Action group名と説明を入力します。説明は文書化のためのものであり、プロンプトには含まれません。次に、APIを格納するLambda関数を指定します。このLambda関数の背後には、1つ以上のAPIを持つことができるため、これをAction groupと呼んでいます。このLambdaを使用して、社内でホストしているか、API GatewayやAWSの他の部分にあるかに関わらず、外部APIを呼び出すことができます。
Lambda関数の背後にあるAPIについて大規模言語モデルに情報を提供するために、OpenAPI仕様も提供します。これにより、API名、説明、パラメータ、データ型、オプションか必須かなどを記述できます。この情報を大規模言語モデルに送られるプロンプトに含め、顧客の質問に答えるために利用可能なツールを伝えます。追加する説明は、望む精度を達成するために非常に重要です。
オプションパラメータと必須パラメータについて話すと、ユーザーが「ウォーターシューズを探したいのですが」と尋ねた場合を考えてみましょう。そして、サイズが必須パラメータである靴の検索APIがあるとします。このとき、モデルは「どのサイズの靴をお探しですか？」と尋ねることになります。この対話を可能にするには、human inputを許可する必要があります。 モデルに人間に質問させるかどうかを指定できるようにしています。「はい」と答えると、会話履歴から見つけられない必須パラメータについて、モデルが人間に入力を求めます。
human inputを許可しない場合、単に「これ以上進めません」と言うか、設定によってはエラーメッセージを表示するだけです。自動化されたワークフロー（例えばメールの分類など）に我々のサービスを利用している顧客も多くいます。そういった場合は人間との対話がないため、必要な情報がない場合はシステムがエラーを出すことを好みます。しかし、チャットインターフェースを構築している場合は、「Allow Human Input」オプションを有効にすべきです。これにより、エージェントがどのAPIを呼び出すべきか、どのパラメータを使用すべきか判断できない場合、人間に確認を求めることができます。
複数APIを使用した複雑なリクエストの処理
必要な情報（エージェントの名前、 利用可能なツールやAPI、指示内容、human inputを許可するかどうか）を追加したら、テストウィンドウで直接チャットエージェントをテストできます。ユーザーインターフェース全体をセットアップしなくてもテストできるのです。下部のテストウィンドウでチャットのテキストを入力できます。私はウォーターシューズについて尋ねようと思っていました。これまでのチャット履歴も確認できます。 また、「Click to view trace」というリンクもあります。traceとは何か見てみましょう。
traceを使うと、large language modelが特定の決定を下した理由を確認できます。モデルが次のステップを決める際の思考プロセスや根拠を見ることができます。また、観察結果に関する別のtraceイベントも確認できます。invocation typeは停止理由を示しており、完了したことを示しています。traceの詳細については、プレゼンテーションの終わりの方でさらに詳しく探り、より複雑な例を示します。
では、これらのタスクをどのように調整しているのか詳しく見ていきましょう。Amazon Bedrockのエージェントは、ユーザーのリクエストと提供されたツールを受け取り、それらのツールやAPIに基づいて小さなタスクに分割します。そして、正しい順序でステップバイステップで実行し、途中でエラーが発生した場合には修正するか、必要に応じて追加情報を求めることができます。内部で何が起こっているのか、もう少し詳しく見てみましょう。
ユーザーが「ウォーターシューズが欲しいのですが」とJonathanの質問のように尋ねた場合、ユーザーの視点からは単に「こちらがウォーターシューズの選択肢です」といった自然な応答を受け取るだけです。 しかし、もう少し深く掘り下げて、ユーザーが青いウォーターシューズを求めた場合に何が起こるか見てみましょう。裏側では、エージェントがその特定のモデルとバージョンに最適なプロンプトを構築します。
私たちがプロンプトエンジニアリングを代行します。エージェントは会話の冒頭のプロンプトを取り、「これらのツールが利用可能です」と伝えます。そして、OpenAPI specで提供された説明、パラメータ、その他すべての情報を含むAPIのリストを示します。次に、ユーザーの質問について考え、次のステップを決定し、特定の形式で応答するようモデルに要求します。各モデルベンダーと協力して、最適なプロンプトを構築しています。
これらのプロンプトを見ることができるか疑問に思うかもしれません。良いニュースは、見ることができるということです。方法は2つあります。画面内でプロンプト編集を提供しています。詳細設定で、生成されたプロンプトを確認できます。もう1つの方法は、Bedrockの呼び出しログを通じてです。これをオンにすると、すべての入出力トークンがS3にログとして記録され、プロンプトを確認できます。これらの画面を通じて喜んで共有します。さらに、編集画面では、考慮されていない特定のエッジケースがある場合、プロンプトを修正することができます。
つまり、最適なプロンプトを構築し、ユーザーの質問を挿入し、Generative AIモデルに送信して、特定の形式で出力するよう要求します。その形式は次のようになります。アクション名、製品検索があり、 これはOpenAPI specの説明から来ています。パラメータがどうあるべきかを分解して説明します。Agentsがこれらすべてを代行してくれるので、コードを書く必要はありません。
このモデルが私たちに代わって行っている自然言語処理の作業量を考えてみてください。まず、ユーザーのリクエストをAPIに従って分類します。次に、すべてのデータをパラメータに抽出します。色：青、カテゴリー：靴、説明：ウォーターシューズというように。これを自分でコードを書くとすれば、膨大な自然言語処理のコードが必要になります。モデルはこのような分類やテキストからの情報抽出タスクが非常に得意だと私たちは考えています。
Generative AIプロジェクトのベストプラクティス
ここでは、エージェントがオーケストレーターとして機能しています。エージェントは「ユーザーの質問に対してこのように応答してください」とエージェントに返します。そして、エージェントはあなたのLambdaを呼び出し、ここにAPI名を提供します。これは、OpenAPI仕様の一部として指定したパスです。この場合、listProductsで、そこにパラメータを追加します。Lambdaを呼び出し、あなたのコードが特定の商品検索APIを呼び出します。
戻ってくるのは、Buy with Prime APIを使用しており、Jonathanが説明したように、GraphQLを使用してJSONが返ってきます。欲しい詳細、つまり商品IDや説明などが送り返されます。両方とも同じ会社からの2つのウォーターシューズであることがわかり、エージェントに戻ってきます。エージェントは単にJSONをエンドユーザーにダンプするわけではありません。代わりに、新しいプロンプトを構築します。再び、その特定のモデルとバージョンに最適なプロンプトを作成します。
ここまでの会話履歴を取り、これには元の質問が含まれます。また、モデルからの以前の応答も含めます。「これがあなたの考えで、これがあなたのアクションで、これがあなたが私に指示した入力です」と言います。そして、「これが観察結果です」と言います。これが検索結果になります。つまり、検索結果をアクションへの回答として提供します。そしてこれがGenAIモデルに送られます。
GenAIモデルは次のような回答を返します。最終回答、「いくつかの良い選択肢があります。AnyCompany Athleticsには2つのウォーターシューズがあります。」注目すべきは、2つの別々の会社からの2つの回答を1つの文にまとめたことです。同じ会社からの2つのウォーターシューズだと言っています。ここで、エージェントは最終回答のフォーマットを取り除き、アプリケーションにそのまま返します。「いくつかの良い選択肢があります。AnyCompany Athleticsには2つのウォーターシューズがあります。」というように。これで、1つのAPIを使用した簡単なオーケストレーションの方法がわかりました。
では、複数のAPIがある場合はどうでしょうか？今度は複数のAPIを必要とする質問をしてみましょう。「ウォーターシューズの価格はいくらで、購入者の評価はどうですか？」OK、ここでは2つの質問があり、おそらく2つの異なるAPIが必要です。価格を知りたいし、そのシューズを購入した人々の評価も知りたいです。ここで1回の呼び出しを行い、エージェントを呼び出します。「ウォーターシューズの価格はいくらで、購入者の評価はどうですか？」がお客様の質問です。
さて、Buy with Prime エージェントに対して invoke agent コールを行います。 エージェントは、ユーザーの質問と、その特定のモデルとバージョンに最適なプロンプトを組み合わせ、Generative AI の基盤モデルに送信し、「これらのツール、これらのパラメータ、この質問に基づいて、次のステップは何ですか？」と尋ねます。
エージェントはおそらく Product Lookup のようなものを提案するでしょう。 「次のステップは Product Lookup API を呼び出すことです」と言うでしょう。そこでエージェントはそれを呼び出し、ウォーターシューの価格を見つけます。あなたは順番に Product Lookup を呼び出し、結果を返します。前のスライドと同じように。 その結果を会話履歴に追加します。会話履歴には、顧客の元の質問と基盤モデルからの前回の応答が含まれています。そして、「次のステップは何ですか？」と尋ねます。まだ質問が1つ残っているので、reviews lookup を行い、他の購入者がウォーターシューについて何と言っているかを調べるよう指示するでしょう。
そこで、エージェントに Reviews API を呼び出すよう指示します。そして、あなたの Lambda を呼び出し、Lambda が Buy with Prime API を呼び出して製品レビューを取得します。そしてそれらが返されます。 再び、最後のアクションの結果、これまでの会話履歴、ユーザーの元の質問を取り、今度は基盤モデルが応答します。もう答えるべき質問はないので、おそらく「ウォーターシューの価格は9.99ドルで、ユーザーの評価は4.9星です」というような回答になるでしょう。私は20年間ウォーターシューを買っていないので、もしかしたらインフレで少し上がっているかもしれません。でも、これは Black Friday セールか Cyber Monday のセールだと考えましょう。このように、複雑なリクエスト（複数のステップを必要とするリクエストを複雑なリクエストと呼びます）を受け取り、あなたが提供した API を使用して、その特定の顧客の質問を解決できたことがわかります。
エージェントについて深く掘り下げてきましたが、 ここでベストプラクティスについて話しましょう。これらのベストプラクティスの一部はエージェントに特化したものですが、一部は Generative AI や ML 開発全般に適用できるものです。テストを自動化し、トレースイベントを使用し、必要なデータを持ち込むことです。最初のものから詳しく見ていきましょう。テストを自動化することです。AI や ML の作業を行う際には、 まず golden utterances のセットを作成することを強くお勧めします。これは、顧客がチャットインターフェースで尋ねそうなことです。そして golden responses のセット、つまり正解と期待される回答のセットを用意します。これらのテストを自動化し、フローを通して、yes か no、または correct、あるいは何らかのスコアを与えるようにします。
これを行うことで、プロジェクトの速度が上がります。ほとんどの場合、これを行うと2倍速くなり、時には10倍速くなることもあります。なぜなら、システムに変更を加えるたびに、チャットインターフェースや自動化されたワークロードの精度を確認できるからです。エージェントや基盤モデルをどのように使用しているかに関わらずです。ここでの難しい点は、Generative AI を扱う場合、常に同じ答えを返すわけではないということです。同じ正解を返すかもしれませんが、表現が少し異なる場合があります。期待する正解と完全に文字列が一致するかどうかをチェックしているだけだと、ほとんどの場合失敗してしまいます。なぜなら、常に同じ答えを返すわけではないからです。
では、この問題をどのように解決するのでしょうか？いくつかの方法があります。実際には多くの方法があり、この主題全体に関する論文も書かれていますが、ここでは2つほど紹介しましょう。1つ目は、ROUGEやROUGE-Lなどの統計を使用する方法です。これらは、ゴールデンスタンダードとして設定したものと、Generative AIモデルから出力されたものとの間の最長共通部分文字列や重複量を見ます。そして、パーセンテージを設定して、「ROUGEとROUGE-Lでこのパーセンテージ以上でなければならない」と言えます。ROUGEには様々な種類があり、実装も比較的簡単で、スコアを返してくれます。そして、「合格するためには、このスコア以上でなければならない」と設定するだけです。もう1つの方法は、私たちが社内で使用しており、強くお勧めするアプローチですが、foundation modelを使ってテストを自動化し、結果を判断することです。
LLMについては、多くの研究で示されているように、結果の一貫した注釈付けにおいて、人間のアノテーターよりも効果的であることが多いのです。そこで、LLMに「これが期待した結果で、これが得られた結果です。同じですか？違いますか？どう違いますか？」と尋ねるか、あるいはスコアリングを依頼し、最低スコアを設定します。このような自動化された精度テストを導入すれば、プロジェクトの進行速度が大幅に向上します。なぜなら、エージェントに関係するかどうかに関わらず、システムに変更を加えるたびに精度テストを実行し、思いもよらないことで精度に影響を与えていないかを確認できるからです。
次のベストプラクティスは、トレースイベントを活用することです。トレースイベントは私たちのAPIから提供されます。InvokeAgent APIはストリーミングAPIです。そのため、レスポンスだけでなく、同じストリーム上で他のイベントも返します。これらのイベントが、先ほどお見せしたトレースイベントです。これは、何が起こっているかを確認し、ユーザーに情報を提供するのに役立ちます。ご覧の通り、1つのユーザーリクエストが複数のAPI呼び出しや、large language modelへの複数の往復を引き起こす可能性があります。このような処理が行われている間、ユーザーに「これは止まっているのか？」と思わせたくありません。そこで、UIを更新し、「product searchを呼び出しています」「製品を検索しています」などと伝えます。私たちは、モデルの思考プロセス、呼び出すAPI、そのAPIの結果を提供します。これにより、リアルタイムで最新情報を提供し、「これらすべてが進行中です」と伝えることができます。そうすれば、ユーザーは単に待っているだけだとは思わないでしょう。
では、これをどのように実現するのでしょうか？私たちのAPIには、enableTraceフラグがあります。True/Falseで設定でき、デフォルトではFalseですが、Trueに設定することをお勧めします。そうすることで、それに基づいてユーザーエクスペリエンスを構築することもできます。 こちらは少し複雑な例です。「サイズ9のウォーターシューズを探しています」というリクエストです。そして、これが得られたレスポンスです。レスポンスを特別にXML形式でフォーマットしています。これは、先ほどのHTMLとJavaScriptのインターフェースで見たように、ユーザーインターフェース用に一部の情報を抽出したかったからです。
では、その背後にある理論的根拠とトレースイベントを見てみましょう。ここでは、なぜこのように処理したかという理由付け、つまり思考プロセスが見られます。「この質問に答えるために、Buy with Prime Action groupのlistProducts関数を使用して製品をリストアップします」と述べ、その後、listProductsの呼び出しトレース、Action group、そして結果である観察が示されています。これを利用して、ユーザーに最新情報を提供し続けることができます。
最後のベストプラクティスは、必要なデータを持ってきて、不要な余分なデータは持ってこないことです。APIが適切な情報を返すようにし、ユーザーの質問に答えるのに不必要な情報をフィルタリングしてください。これを行えば、大規模言語モデルがそのデータを自然言語の応答に含める可能性が低くなります。特に、ユーザーに絶対に見せたくないものは、返答に含めないでください。APIから機密情報が返ってくる場合は、Buy with PrimeのGraphQL機能を活用してください。これはBuy with Prime APIの素晴らしい機能で、GraphQLを使用すると応答の形を整えることができ、ユーザーが求める情報を含み、余分な情報を含まないようにすることができます。これを活用して、不要なデータをフィルタリングしてください。
セッションのまとめと今後のeコマースの展望
さて、皆さんと一緒にこの深掘りを行い、いくつかのベストプラクティスを共有できて本当に楽しかったです。ここでZubeenに戻して、主要なポイントをまとめてもらいましょう。Johnの話を聞くたびに、私は新しいことを学びます。John、Amazon Bedrockと最良の実践についての深い知識を共有してくれてありがとう。Johnが共有してくれた洞察は、この動画を見ている皆さんにとって大変有益なものになると確信しています。
eコマースの進化は驚くべきものでした。テクノロジーのおかげで、私たちの買い物はより便利で速くなりました。過去のeコマースサイトはかなり基本的なものでしたが、今日では次のレベルの進歩について話しています。Amazon Bedrockを通じた生成AIの能力の活用や、Buy with Primeのような提供サービスによって、ショッピング体験が向上しています。今日のセッションの主な焦点は、カスタム統合のためのBuy with Prime APIのパワーを強調することでした。Amazon Bedrockのサーバーレスアプローチにより、技術的なインフラストラクチャを管理する手間なしに、生成AI機能をアプリに迅速に展開し、適応させることができます。
eコマースの未来は、私たちがこれまで想像してきた多くの進歩により、非常に有望に見えます。この旅に参加していただき、ありがとうございます。約束通り、QRコードをご用意しました。 Buy with Primeの関心リストにサインアップしたい方は、こちらからご連絡いたします。Buy with Prime用のQRコードと、Agents for Amazon Bedrock用のQRコードがあります。後者はそのサービスのホームページに移動します。ぜひ写真を撮ってください。
こちらは、興味を引くかもしれないBuy with Primeセッションのリストです。私たちのセッションはBuy with Prime 303で、下から2番目だと思います。もし直接見たい方は、もう1つセッションが残っています。それでも、re:Invent後にはすべてのセッション録画をオンラインで視聴できます。アプリを通じてアンケートにご協力いただければ幸いです。
このセッションが楽しく、そして学びの多いものであったことを願っています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion