re:Invent 2023: AWSのAmazon Bedrockを活用したAI導入事例と実装技術
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Augment creative thinking & boost productivity with AWS generative AI (AIM211)
この動画では、AWSのgenerative AIサービスAmazon Bedrockを活用した実践的なアプローチを学べます。Showpadの事例を通じて、マーケティングや営業でのAI活用法を紹介。さらに、prompt engineering、RAG、fine-tuning、再トレーニングといった高度な技術の実装方法も解説します。AIの導入に悩むエンジニアにとって、具体的なユースケースと技術的な深掘りが一度に得られる貴重なセッションです。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Generative AIを活用したコンテンツ創造の可能性
テスト、1、2、1、2。始める前に、皆さんが正しい場所と時間にいることを確認する必要があります。これはセッションAIM211、AWS Generative AIを使用した創造的思考の増強と生産性の向上です。今日のプレゼンテーションに参加している方々について、もう少し詳しく知りたいと思います。マーケターまたはマーケティング部門で働いている方はどなたですか？オペレーション部長やマーケティングオペレーションの方もいらっしゃいますか？同じPMMの方はいらっしゃいますか？ 素晴らしいですね。eBookなどの長文コンテンツを作成するプロセスをご存知ですよね？私たちは同じ立場にいるわけです。
営業の方はどうでしょうか？営業組織から来られた方はいますか？フィールドセールスの方や、営業チームの部長で、セールスの作業をスピードアップしたい方はいらっしゃいますか？1、2、3、4、5人。素晴らしいですね。お客様向けのコンテンツを作成していますよね？グローバルキャンペーン用のものよりもパーソナライズされていますが、それでもコンテンツです。 では、技術職の方はどうでしょうか？ ソリューションアーキテクト、開発者、AI/MLサイエンティスト、データサイエンティストなどの方はいらっしゃいますか？はい、良いグループですね。
このような構成の方々がいらっしゃって嬉しいです。なぜなら、結局のところ、私たちが何を作るかに関係なく、皆コンテンツクリエイターだからです。 マーケティングの分野、営業の分野に関係なく、種族に関係なく、私たちは皆コンテンツクリエイターです。そして、私たち自身のようなコンテンツクリエイターにAIが提供するものから恩恵を受けることができるのです。
プレゼンテーションの概要と登壇者紹介
皆さん、こんにちは。Re:Inventの火曜日が良い形で終わりに近づいていることを願っています。私はOscar Cedielと申します。 現在、AWSでgenerative AIのシニアAI/MLプロダクトマーケティングマネージャーを務めています。一緒に登壇しているのは、AWSのシニアAI/MLスペシャリストのSilvia Prietoです。そして、ShowpadのチーフソフトウェアアーキテクトであるJeroen Minnaertさんにも、ステージに加わっていただき、大変光栄に思います。
私たち3人で、以下のアジェンダについてご説明します。まず、市場統計とgenerative AIが人々に与える影響についてお話しします。なぜなら、結局のところ、組織内のポジションに関係なく、私たちはステークホルダーを説得し、AIムーブメントに参加してより良い仕事ができるようなソリューションを展開するために、チームに火をつける必要があるからです。マーケティングと営業のユースケースについて詳しく説明します。これらのユースケースは、AIから得られる価値を最も示すことができ、それを自社に取り入れることができると考えているからです。
それでは、Jeroenに Showpad の成功事例を共有してもらいます。彼らの取り組みに触発され、皆さんのアプリケーション、プラットフォーム、ソリューションでどのように実現できるかのアイデアを得られるでしょう。その後、シニアスペシャリストの Silvia が、これまでお聞きいただいた内容を技術的な現実に落とし込み、AWS が提供する generative AI と foundation model についてお話しします。私たちは様々な立場で AI に取り組んできましたが、ここでは全てをまとめて、皆さんの組織で革命を起こすための5つの簡単な始め方をご紹介します。
Generative AIの基本と応用
まず、generative AI の基本から始めましょう。generative AI とは何でしょうか？ 画像、音声、音楽を生成できる AI の一分野であることは知られています。最近では、人々はあらゆることに使っています。帽子をかぶった子犬の画像を生成したり、実際の仕事に使ったりしています。子供たちに寝る前に読み聞かせる物語を生成している人も見かけます。私も guilty です。 また、これまで市場に出回っている非常にシンプルなものから複雑なものまで、様々なツールを使ってグローバルキャンペーンを展開している人も見かけます。真面目な用途にも、そうでない用途にも使われています。
generative AI は、膨大なデータで事前学習された大規模モデルによって支えられており、一般的に foundation model や FM と呼ばれています。これらのモデルは、例えば「パーカーを着たキツネザルを見せて」とか「紫のスーツを着たキツネを見せて」、あるいは「私の製品がどのように見えるか見せて」といった画像を生成できるように学習されています。
自然言語を使ってコンテンツを生成することもできます。例えば、2023年のブランディングガイドラインに沿って、キャンペーンで製品がどのように見えるかを示すといったことです。
Generative AIが専門家に与える影響と市場予測
コンテンツの生成について話す際、人々について触れないわけにはいきません。私は generative AI について話すとき、通常ここから始めます。なぜなら、影響を受けるのは人々だからです。AWS 内部では、様々なチームが generative AI を使えるようにしてきましたが、人々の不安や仕事の安定性に対する疑念を感じることができます。今年 MIT が行った調査では、generative AI を使用している、または使用を計画している専門家たちに意見を聞きました。どう思いますか？メリットを感じていますか？大多数が AI は彼らの仕事にポジティブな影響を与えていると報告しています。
AIは単に仕事量を増やすだけでなく、より質の高い、誇りを持てる仕事をサポートしています。スペイン語ネイティブの私は、他者とのコミュニケーションを洗練させるためにジェネレーティブAIを活用しています。最近では、より高品質な表現ができるようになり、自分の言動に一層の自信を持てるようになりました。 また、AIは一般的に退屈で面倒と思われがちなタスクを軽減することもできます。これらの要素が全て、プロフェッショナルとしての充実感や個人的な満足度に直接影響を与えることは明らかです。
市場を見ると、その変化は劇的なものです。Bloombergによると、今後10年間で市場規模は1.3兆ドルにまで成長すると予測されています。2022年1月時点でジェネレーティブAI市場は400億ドルと推定されていたことを考えると、驚異的な成長です。この1.3兆ドルのうち、少なくとも2,500億ドルは、まだ見ぬ新しいソフトウェアやアプリケーションの形で現れると予想されています。
そのため、Gartnerは早くも2026年までに、少なくとも1億人が「ロボ同僚」と呼ばれるAIと協働することになると予測しています。実際、これは今まさに起きていることで、皆さんも既に体験しているかもしれません。AWSの社内では現在、Amazon Bedrockを通じてAIモデルと対話し、マーケティングコンテンツの生成や質問への回答などを行っています。つまり、Gartnerが予測する「近い将来、多くの労働者が経験する生活」を、私たちは既に先駆けて実践しているのです。
最も価値を生み出すユースケースを見てみると、McKinseyの調査で興味深い結果が出ています。AIを活用している組織に「どのユースケースが最も価値を生み出しているか」を尋ねたところ、AIがもたらす全価値の75%を占める5つのユースケースが特定されました。そのうち、マーケティングと営業だけで全体の少なくとも20%を占めています。だからこそ、マーケティングと営業部門にAIを導入することで生まれるインパクトは、組織全体にジェネレーティブAIの未来を示すことができるのです。製造、新製品設計、新規事業開発など、AIを活用できる全ての機能に展開した際の可能性を示すことができます。ただし、組織内でその価値を説得する必要があります。そのため、マーケティングと営業が非常に効果的であることが実証されているのです。
マーケティングにおけるGenerative AIの活用
では、なぜマーケティングにジェネレーティブAIを活用するのでしょうか？マーケターの視点から見ると、ジェネレーティブAIはコンテンツ制作の方法を大きく強化できます。以前よりもはるかに多くのアイデアを生み出すことが可能になります。私の場合、以前はGo-to-Market施策のアイデアを考えると、1週間で3〜5つの方法を思いつく程度でした。そして、それを様々な人と共有し、ドキュメント上でフィードバックをもらうなどのプロセスが必要でした。今では、ボタン一つで新しいアセットのワークフローを生成し、自分のアイデアが市場でどう見えるかを確認できます。そして、必要な限りこのプロセスを繰り返すことができるのです。
これは、お客様とのエンゲージメントの方法を変革することができます。Salesforceや他のプラットフォームからの内部データや履歴データを活用して、非常にパーソナライズされたコンテンツを生成できるだけでなく、マーケターが新しい市場参入方法を生み出し、生成することもできるからです。モデルに対して、こう言うことができます。
「これが私たちの従来の市場参入方法で、ここが効果的だと考えている段階です。」このコンテンツを市場に投入するための従来の方法を5つと、非常に創造的な方法を3つ作成してください。モデルが何を思いつくか見て、そこからインスピレーションを得ることができます。これは確実に生産性を向上させます。一部のチームにとっては、スピードアップにつながります。新製品についてのアイデアをいくつか入力するだけで、新しいプレスリリース文書の下書きを数秒で生成できるようになりました。他のチームにとっては、コンテンツの改訂にかかるサイクル数を減らすことができます。
社内で独自のマーケティングソリューションを作成することで、機密性とコンプライアンスを高めることができます。マーケターが外部に出て、誤ってプロンプトや出力の形で機密データを共有することを強制しないからです。すべてを内部に保持できます。コンプライアンスが向上するのは、generative AIがより多くのコンテンツをより頻繁に、より低コストでチェックできるからです。これにより、例えば地域をまたいだコンテンツモデレーションにおけるコンプライアンスの達成を支援します。
セールスにおけるGenerative AIの活用
では、なぜセールスにとって重要なのでしょうか？私たちは、セールス担当者に販売してほしいのです。顧客と話をして、取引を成立させてほしいのです。generative AIは、セールス担当者がキーボードから離れて会議室に入るのを助けることができます。なぜなら、メール、契約書、提案書などのコンテンツ作成に多くの時間を費やす必要がなくなるからです。承認やフィードバックを得るために、チームと共有する何かの簡単なバージョンをすぐに作成できます。自分の顧客関係を再構築することもできます。
AWSでは、私たちが作成したプロトタイプを使って非常に創造的なセールス担当者を見ています。彼らは顧客に関するいくつかの詳細や逸話的な情報を入力して、非常に特定の業界セグメントにいる顧客に基づいてメールをカスタマイズしています。また、顧客との会話の内容も反映させています。例えば、昨晩のサッカーの試合について話したとすれば、適切な実装があれば、そのような形でセールス担当者がより個人的になれるようにすることができます。
セラーの才能を強化することができます。なぜなら、セラーはカメラを見て ピッチを行い、生成AIからリアルタイムのフィードバックを得ることができるからです。「オスカー、話すのが速すぎます。ゆっくり話してください。あなたの聴衆はこの地域にいます。私たちのデータベースによると、少なくとも25%スピードを落とす必要があります。オスカー、その用語は使うべきではありません。」少しずつ、セッションエキスパートからフィードバックを受けて、より優れたセラーになることができます。
そして、パターンを解き明かし、 インサイトを得ることができます。それも、大きなスピードだけでなく、より高い精度で行えます。なぜなら、すべての情報をフィードして、セラーにこのアカウントはこの段階にあり、これらのチケットがオープンしていると伝えることができるからです。このチケットを閉じるのを手伝えば、取引の成立に役立ちます。提案書を作成する際、この提案書はこれらの地域で影響力がありました。そして、自動車関連なので、影響力があることが示されているこのメールを使用すべきです、といった具合です。これらは、セラーにとっては数日や数週間かかっていたインサイトです。私たちは、セラーがコンピューターの前で数日や数週間を過ごし、顧客と話をしないことは望んでいません。
Generative AIを活用したマーケティングと販売のワークフロー
さて、このようなワークフローを実践で想像してみると、 次のようになります。私がProduct Marketing Managerとして、アイデアを思いつきます。例えば、靴工場で働いているとします。 私の出身地シアトルの人々は、このような反射性があり快適な靴を持つべきだ、というアイデアを思いつきます。そこで、マーケティングソリューションにアクセスして製品の説明を入力するだけで、ソリューションはブランドガイドラインや会社情報に基づいて、生成されるものがそれらのガイドラインに適合することを確認します。
さらに進んで、画像のようなものを生成することもできます。 つまり、私のエンジンが、私が販売している製品の種類、材料、要件、取引を知っていれば、それに関する画像を生成し、すぐに人々に送ることができる説明を提供できます。「X、Y、Zの快適さと耐久性でシアトルを体験できる靴についてどう思いますか？」それは素晴らしいですね、プレスリリースが必要です。すでに生成しているので、ここにドラフトがあります。耐久性がない場合はどうでしょうか？反射性だけの場合はどうでしょうか？プロンプトの「反射性」という言葉を変更するだけで、マーケティングワークフロー全体を一瞬で再生成できます。 さて、販売の時が来たら、
セラーは私が作成したプレスリリースを取り、それを消化して、その人が全体を読まなくても理解できるように数文で要約することができます。
私は、クリエイティブな販売者が顧客のブランドガイドラインに基づいて画像を生成しているのを見てきました。例えば、こんな感じです。「Laura様、お会いできて光栄です。こちらの靴は貴社の店頭で大ヒット間違いなしです。貴社の棚に並んだ様子をご覧ください。また、貴社の市場トーンにもぴったりマッチしています。」このような創造性が実践されているのを見ると、顧客にとってすぐに印象的な効果があります。プラットフォームでの過去の成功情報を活用することで、契約書の下書きまで作成できます。さらに、これらの契約書を交渉をシミュレートするシステムに通すことで、販売者に渡せる情報を提供する実装も見てきました。顧客がこう言った場合、その取引を成立させるために最も経済的で価値のある回答がこれです、というような具合です。
AWSのGenerative AIプロトタイプ「PartyRock」の紹介
先ほど、AWSでいくつかのチームと協力してきたと言いましたが、ある時、私のプロダクトマーケティングチームがAIの可能性を示すよう依頼してきました。そこで私たちはこのプロトタイプを作成しました。これは急速に発展し、今日私たちが知るPartyRock、Amazon Bedrockのプレイグラウンドとなりました。皆さんにもぜひ試していただきたいと思います。このプロトタイプは、PMMの組織を調査した際に、新製品リリースのために多くの文書を作成しなければならないという声を聞いて作成しました。そこで、3つの基本的なユーザー入力で、一度に好きなだけ多くの文書を生成できるものを作りました。
実際に動作を見てみましょう。これが今日皆さんが知っているPartyRockの基本的なUIです。3つの白いフィールドが情報を入力する場所です。製品名は「Walker Shoes」で、新しい快適な反射素材の靴のラインです。次に発売日を入力すると、すぐにツールがコンテンツの生成を開始します。
これらの異なる出力の背後には、Amazonの10の文章作成原則に基づいてAmazonianのように書くためのプロンプトがあることに注目してください。LinkedInの投稿は400文字で作成する必要があります。これはAWS社会メディアチームのガイドラインです。そして、ウェビナーはこの3つのガイドラインに従う必要があります。これはAWSイベントチームが私たちのツールのガイドラインとして示しているものです。さらに、モデルが書いたものに対して提案を求めるための追加の列も作成しました。つまり、コンテンツの生成が終わったら、それを見直して、さらに良くするための5つの提案を出してください、というわけです。これらの提案をPMMが見て、「おもしろい、これを文書に取り入れよう」と言えるようになります。
このプロトタイプの作成には1時間、プロンプトエンジニアリングには5時間かかりました。現在、AWSの多くのチームで使用されており、基盤モデルのいくつかの機能に依存しています。基盤モデルを使えば、優秀なコーダーを素晴らしいコーダーに変えることができます。そしてマーケティングや営業にもコーダーがいます。Wikiページのバックエンドに入ってWikiコードを変更したり、イントラネットページのウィジェットを提供するためにイントラネットのウィジェットに入ったりする必要がある場合、時にはコーディングが必要です。HTMLかもしれませんし、CSSかもしれませんし、他のものかもしれません。しかし、そのコードをエンジンに送って、「このコードを書き直して、これが必要なんだ」と言えば、エンジンがそれを行ってくれます。
企業では同じ質問に対して異なる回答があり、中には私の7歳の子供と同じくらい古いものもあれば、より適切なものもあります。人々に適切な回答を提供したいのですが、そのためのウィジェットを作成することができます。また、情報を数学的な解釈に変換するためにembeddingsを使用することで、これまで気づかなかった洞察を明らかにすることができます。そして、まさにそれが私たちの顧客が今日行っていることなのです。 例えば、Omnicomグループの一員であるAnnalectは、AWSの生成AIを活用して、エンド・ツー・エンドの広告ソリューションを作成しています。自動的にセグメンテーションと広告資産を生成し、人間のチームが市場に出す前にレビューを行います。
Showpadの事例：Generative AIの実践的活用
このアプローチにより、市場投入活動のサイクル数を減らすことができます。また、Codaは600以上のツールのプラットフォームを生成AIと統合することで、世界中の何百ものチームの効率を高めています。そして、Showpadは私が言及した素晴らしい例で、セールス担当者がより優れた営業活動を行い、より多くの取引を成立させるのを支援しています。しかし、Showpadのストーリーを語るには、ShowpadのChief Software ArchitectであるJeroen Minnaertさん以上に適任な人はいません。Jeroenさん、ようこそ。
ありがとうございます、Oscar。これは機能していますか？はい？素晴らしい。ありがとうございます。はい、今は機能しています。皆さん、こんにちは。私はJeroenと申します。Showpadのチーフアーキテクトです。今日は、私たちの旅、私たちのストーリー、 私たちが何を構築し、どのように構築したかについて少しお話ししたいと思います。まず、一歩下がって、セールスとマーケティングを見てみましょう。Showpadの視点から見ると、主に2つの課題があります。一方では、最も関連性の高いマーケティングコンテンツを見つけるのに苦労しているセラーがいます。もう一つの課題は、セールス担当者がトレーニングとコーチングに苦戦していることです。特に、その情報とマーケティングコンテンツを買い手との魅力的な会話に変えることに苦労しています。
そのため、ひどい買い手体験が生まれ、ひどい機会損失と収益の損失が発生します。そこで、Showpadはこれを解決しようとしています。 マーケティング、セールス、そして買い手が一緒になれるプラットフォームを提供することで、セールスが買い手とより魅力的な会話を持てるようにしています。買い手との会話からより効果的な結果を得られ、一般的に、より多くの機会が取引に転換され、より多くの収益につながるようにしています。マーケターがコンテンツをアップロードできるコンテンツプラットフォームを提供し、セラーがそのコンテンツとツール、コーチングを使って顧客と共有できるようにしています。また、買い手とセラーにデジタルディールルームの形を提供し、そこで協力して取引を成立させることができます。
非常に大まかに言うと、Showpadはベルギーを拠点とする企業で、約500人の従業員がいます。年間経常収益1億ドルに近づいており、 世界50カ国以上で約1,400の顧客に1つのSaaSプラットフォームでサービスを提供しています。活動面では、毎月約670万人の買い手が私たちのプラットフォーム上でセラーとやり取りしています。また、私たちは完全にAWS上に構築されています。 約90のサービス、実際にはもう少し多いのですが、使用しているものすべてのアイコンをこのスライドに載せてみました。どのようなものを使っているかが分かると思います。ただし、今日特に使用するものについては、アイコンが見つからなかったんです。それはBedrockで、後ほど少し詳しく説明します。
Showpadのアーキテクチャと指針原則
でも、今日は AI について話しましょう。 では、今年私たちが生成 AI で行ったことを振り返ってみましょう。数ヶ月前に始まったばかりですが、いくつかのユースケースを検討することにしました。多くの企業がやっているような単なるチャットボットを作るのではなく、セールスに特化した本当に重要で独自のユースケースに焦点を当てることにしました。これにより、現場での加速を支援し、セールス担当者が難しいと感じる作業を減らし、顧客との信頼関係を築くことに集中できるようにしました。今日は、1つではなく4つのユースケースをご紹介します。私たちはこの4つを構築し、その威力をお見せしたいと思います。
最初のユースケースは、AI生成アセットサマリーと呼ばれるものです。 これは、文書やテキストの要約を作成するという生成AIの一般的なユースケースを基にしています。私たちはこのアイデアを採用し、セールス向けにアレンジしました。 基本的に、顧客が質問している間にセールス担当者が長文を読むのは難しいだろうと考えました。そこで、文書を取り込み、大規模言語モデルに対して、その文書に基づいてFAQを生成するよう指示しました。これにより、バイヤーとセラーが会話をする際、セラーは簡単にバイヤーの質問を受け取り、メールやWhatsAppなどを通じて回答を返すことができます。
さらに一歩進めて、1つの文書から質問を生成できるなら、すべての文書について質問できるようにしてはどうかと考えました。 そこで開発したのが AI-powered search です。質問を受け取り、それをあなたの文書ベースに照らし合わせて、答えをテキストとして表示します。これを簡単にメールにコピーできるようにし、その情報を見つけた元の文書も全て参照できるようにしました。
でも、ラップトップを持っていない場合はどうでしょう？ コンピューターを持っていない状況で、例えばラスベガスにいて顧客とゴルフに行くとか、顧客と豪華なディナーに行くような場合はどうでしょうか。そういった場合、オフラインで準備したいかもしれません。見た内容に基づいて自分用の試験を作成したいかもしれません。そこで、私たちは AI-generated test questions も提供しています。AIを使って質問、正解、そしていくつかの選択肢を生成し、顧客との対面ミーティングに最適な準備ができるようにしています。
最後に、厳密には生成AIではありませんが、ぜひ紹介したい機能があります。 準備が整い、顧客と共有する準備ができたコンテンツや情報がすべて揃ったら、PitchAI機能を使って自分の声を録音し、ピッチを録画することができます。すると、声のトーン、ボディランゲージ、笑顔の回数、顧客に話しかけている際の体の揺れなどの情報を提供します。そして、顧客の前でのパフォーマンスを向上させるためのアドバイスを的確に提供します。以上が、私たちが構築した4つの機能、4つのユースケースです。
でも、秘訣は何でしょうか？どうやってこれらの機能にたどり着いたのでしょうか？これらを実現できた核となる要素は何なのでしょうか？ここからは少し技術的な話になります。 実は、要素は3つしかありません。まず、ツール、データ、専門家、そして専門知識といった環境に自分たちを取り囲むこと。次に、機能を再利用できるように、疎結合のコンポーネントからなるアーキテクチャを確保すること。これが1から4への進化を可能にしました。そして最後に、成熟したソフトウェアエンジニアリングの実践を適用できる、優れた指針を持つことです。
Amazon Bedrockの概要と提供モデル
環境は非常に重要です。なぜなら、AIフレンドリーな環境でAIアプリケーションを作成したいからです。私たちはまず、適切な人々に適切なデータへのアクセスを提供できるようにしました。本質的に、データメッシュプラットフォーム全体を構築し、強力なガバナンスと合わせて、アプリケーション開発の単一の信頼できる情報源を確保しました。その上で、AWSを基盤としてデータプラットフォームを構築しました。そのため、複数のサービスを使用し組み合わせる際には、完全にサーバーレスでコスト最適化された単一のクラウドネイティブプラットフォームを持っており、顧客に最も効果的なソリューションを提供できるのです。
そして最後に、私たちは専門知識で自分たちを取り囲みました。まず自社のエンジニアのスキルアップを行いました。さらに、AWSのチームと密接に協力し、外部のパートナーとも提携して外部の専門知識を取り入れ、成功への準備を整えました。これが2つ目の要素であるアーキテクチャにつながります。先ほど言ったように、アーキテクチャは疎結合のコンポーネントに関するものであり、 FAQがAI搭載の検索に進化するように、それらを再利用できるようにすることです。
そしてそれは基礎から始まります。優れた機械学習インフラを持ち、エンジニアがML opsを利用できるようにすることから始まります。そうすれば、基盤モデルや大規模言語モデルをデプロイする際には、ボタン一つで済むのです。また、コンテキスト検索も追加しました。これにより、基盤モデルを知識で拡張できます。例えば、Showpadが持つ追加の知識や、顧客からの追加データなどです。さらに、モニタリングとフィードバックのコンポーネントも追加しました。これにより、本番環境に移行後も、パフォーマンスを継続的に測定し、うまくいっていることや問題が発生していることがあれば、即座に変更を加えることができます。
そしてこれらすべてがオーケストレーション層で統合されます。このオーケストレーション層が最終的に、美しいUXを通じて顧客にサービスを提供するアプリケーションとつながります。この話題については何日でも話し続けられますし、もっと深く掘り下げることもできますが、今日は基盤モデル、つまり大規模言語モデルの側面にのみ焦点を当てます。 他の部分について質問がある場合は、セッション後にお聞かせください。
それでは詳しく見ていきましょう。今日の状況を見ると、特に昨年と比べて、ソリューションの選択肢がかなり広がっていることにお気づきかもしれません。事前に学習済みのAPIを提供するOpenAIのような完全なパッケージソリューションから、Databricksのような、モデルの管理とデプロイは可能だが自己学習が必要なソリューション、さらには非常に管理されたAmazon Bedrockのようなものまで、幅広い選択肢があります。そして、自己ホスティングと自己学習を行うカスタムモデルもあります。つまり、多様なソリューションが存在するということです。それは同時に、多くの疑問が生じることも意味します。しかし、Showpadにとっては、選択肢はすぐに絞られます。大規模な企業向けに販売しているため、顧客に対する多くのコンプライアンス制約があるからです。一部のベンダーは、データの移動を要求するため、私たちにとってはそもそも選択肢になりません。これは、従来から避けてきたことです。
また、1,400の顧客それぞれにカスタムモデルを開発することは、スケーラブルではありません。これは詳細に行うことができないため、私たちの選択肢から除外されます。
Amazonが私たちに提供してくれるのは、そのサービスを通じてこの全ての領域をカバーする能力です。Amazon SageMaker JumpStartのような、モデルを素早く自身のマシンにデプロイできるものから、Amazon Bedrockのような非常に管理されたプラグアンドプレイ的なものまで。私がこれを強調するのは、私たちのソリューションがこの領域全体にわたっているからです。アプリケーションをデプロイするために必要な部分を選んで使用しています。
では、それはどのようなものでしょうか？まず、re:Inventのブレイクアウトセッションには優れたアーキテクチャ図が欠かせません。Silviaはさらにいくつか用意しています。しかし、このスライドから覚えておいていただきたい重要な点が3つあります。左側にあるのは、認証や認可といった従来のAPIメカニズムです。これらは依然として必要です。Gen AIがこれを解決するわけではないので、それをデプロイするためのエンジニアリングとフレームワークが必要です。
2つ目に強調したいのは、図の右側で、複数のモデルを使用していることです。より会話的なアプリケーションにはAmazon Bedrockを使用し、要約作成にはSageMakerを使用しています。例えば、JumpStartでLlamaをデプロイしています。つまり、間にあるLambdaで一種のスイッチボードを持ち、アプリケーションに応じて必要なものを選択しています。下部では、OpenSearchと統合して、大規模言語モデルを顧客からの追加知識や、そこにインデックス化された情報で補強しています。
最後に、しかし決して軽視できないのが、3つ目の要素である私たちの指針原則です。これこそが全てを一つにまとめ上げ、成熟した方法で製品を顧客に提供することを可能にします。Showpadには6つの原則があります。それらを簡単に説明し、その後1つに焦点を当てます。まず、人間の主体性から始まります。AIの時代においても、私たちは人間による制御を望んでいます。特に企業においては、人間による監査と監視が必要だと考えています。
Showpadの観点から言えば、Amazon Bedrockを使用し、ClaudeやLlamaのようなAIモデルを利用していても、顧客にそのサービスを提供する責任は私たちにあると考えています。したがって、説明責任がこの分野では重要です。透明性も同様に重要です。AIがどこで使用され、どのデータが使用されているかを顧客に示し、教育することは、顧客との信頼関係を築く上で非常に重要です。
もちろん、堅牢性も必要です。本番環境に投入されるソフトウェアアプリケーションは、十分に設計され、ソフトウェア業界で何十年も機能してきたベストプラクティスに従う必要があります。次に、包括性があります。これについては後ほど詳しく説明しますが、包括性とは公平性のことです。差別をなくし、これらのアプリケーションを使用する全ての人が適切に使用していると感じ、公平に扱われていると感じるようにすることです。
最後に、誠実性があります。誠実性とは、私たちにとって、顧客との関係の基盤となる法的、社会的、コンプライアンス上の枠組みを尊重することを意味します。 ここで、包括性に焦点を当ててみましょう。これについてさらに質問がある場合は、後ほど教えてください。先ほど使用したPitchAIの例を取り上げましょう。ピッチを録音する際、当然ながら特定の言語で行います。英語、フランス語、ポーランド語かもしれません。重要なのは、言語によってそれぞれ独自のペースがあるということです。ポーランド語のような言語は比較的ゆっくりとした傾向があります。フランス語やスペイン語のような言語は、かなり速い傾向があります。
私たちのアプリケーションで行っていることの1つは、言語を検出し、それを言語ベースのベンチマークに変換することです。話している言語に応じて、その言語のベンチマークに基づいて評価を行います。全ての人を同じように扱うのではありません。以上で、私からの最後の考察を終わります。次は、BedrockとそのTechnicalな詳細について多くを語るSilviaに引き継ぎます。私たちは、わずか数ヶ月の間に素晴らしい旅をしてきました。これらのアプリケーションを非常に迅速に、そして本番環境に適した品質で提供することを可能にした、いくつかの本当に重要な要素がありました。私たちは、これを次のレベルに引き上げ、今年がどのような展開をもたらすかを見るのを非常に楽しみにしています。
LLMの性能向上戦略：プロンプトエンジニアリングとRAG
Oscarから、可能性のアートと市場が急成長していることについて聞きました。
本日はご参加いただき、ありがとうございます。また、Showpadがこのテクノロジーを実際にどのように活用しているかについての素晴らしい説明も聞いていただきました。これから、技術的な側面についてもう一歩踏み込んで説明していきます。
Amazon Bedrockをご紹介します。Amazon Bedrockは単一のAPIを通じてアプリケーションを構築・操作できる完全マネージド型サービスです。このAPIを通じて、最先端のモデルにアクセスできます。そして、時間の経過とともに、これらのモデルがより有名になり、お客様からのリクエストがあれば、モデルを追加し続けています。Amazon Bedrockは、プライバシーとセキュリティを重視して一から構築されています。これは非常に重要です。なぜなら、自社のデータを使ってこれらのファウンデーションモデルを活用したいと考えるからです。データが他者と共有されず、データの漏洩がなく、モデルの再トレーニングに使用されないことを確認したいのです。Bedrockを使えば、これらが本当に実現されていると確信できます。また、インフラ管理について心配する必要もありません。すべて対応済みですので、何も心配する必要はありません。
では、提供しているモデルについて説明しましょう。Anthropicは、倫理的で責任ある方法で、つまり憲法的AIの原則に基づいてトレーニングされています。Stability AIは最先端のテキストから画像、画像から画像へのモデルです。Oscarが先ほど示したような、すぐに使えるコンテンツ作成の一部は、このモデルが生成を支援します。AI21 Labsは、メールなどのテキスト生成に優れたモデルです。そして、AWSが独自に生成・製作したAmazon Titanモデルがあります。この場合、テキストと埋め込みのモデルがあります。また、CohereとCommand Cohereもあります。これらのモデルは特に企業向けに構築されており、100以上の言語をサポートしています。したがって、さまざまな地域や国にお客様がいる場合、これは使用するのに最適なモデルでしょう。最後に、Meta Llama 2があります。これは、APIを通じてアクセスできる最初のオープンソースモデルです。
これらのモデルをクライアントに紹介すると、よく「どのモデルを使うべきか」と聞かれます。答えは、状況によって異なります。ユースケースによって異なるのです。考慮すべき3つの要素があります：スピード、精度、コストです。これらの要素によって、使用すべきモデルが決まります。例えば、小さなモデルは非常に高速で安価ですが、その精度は大規模言語モデルと同じではありません。逆に、大規模モデルは非常に正確ですが、コストが高く、スピードはそれほど良くありません。したがって、これらの要素のバランスを取る必要があります。
これを説明すると、必ず誰かが「でも、全部欲しいんです」と言います。私たちはいつも全てを欲しがるものですよね？答えはイエス、fine-tuningすれば全てを手に入れることができます。特定のタスクに対してfine-tuningを行えば、より小さなモデルを使い、自分のデータを追加して、高速で安価、かつ正確なものを手に入れることができるのです。
Bedrockでできることについてもう少しお話しましょう。先ほど説明したfine-tuningができます。また、Amazon Bedrock用のAgentsもあります。Agentsとは何でしょうか？Agentsはタスクを自動化する方法です。Agentsを設定し、APIを通じて他のソリューションやサービスへのアクセス権を与えることができます。Agentsはあなたの質問やリクエストを受け取り、分析し、APIを通じて他のシステムから情報を取得し、次に最適なアクションを推論して実行します。例えば、特定の顧客グループに彼らが本当に欲しがっている新製品について思い出させるメールを送りたい場合、Agentsに自動的に行わせることができます。
また、provisioned throughputも提供しています。このモデルを大規模に使用し、キャパシティを心配する必要がない場合は、この機能も利用できます。最後になりましたが、Jeroenが彼のプレゼンテーションで言及していたような、ドキュメントのチェックについて、Redis、OpenSearch、Pineconeとの統合されたサーバーレスのベクトルデータベース統合を作成しました。これにより、ドキュメントのベクトル埋め込みをサーバーレスな方式で自動的に作成できます。
大規模言語モデルは明らかに重要ですが、それらはより広範な統合の一部に過ぎません。アプリケーションはLLMだけでは構築できません。他のコンポーネントも必要です。これらのLLMの使用を最適化するには様々な方法があり、今日は性能と精度を向上させるために念頭に置くべき4つの戦略についてお話ししたいと思います。
最初の戦略はprompt engineeringです。prompt engineeringとは、質問の一部としてモデルにどのように振る舞う必要があるかを伝えることです。時にはユーザーに見えないように裏側で行うこともありますが、これはprompt engineerが設定しなければならないものです。これは、良い回答がどのようなものかの例を示すことで、モデルの精度を向上させるのに役立ちます。
例を挙げてみましょう。ここでは、コンテキストのない通常の質問があります。モデルが学習した情報のみを使用して質問に答えています。プロンプトは「新しいスナック食品のためのタグラインを書いてください」で、答えは「Fueled by Nature」です。ここで、プロンプトにもう少し情報を与えると、より良い結果が得られます。例えば、ブルーベリーのグラノーラバーで、自然な原料を強調すると指定すると、応答は「Bursting with Real Fruit & Nutritious Grains」になります。これは前のものより良く、やはり学習した知識を使用しています。
モデルに「あなたは食品業界で働くマーケティングスペシャリストで、これまでに作られたタグラインの3つか4つの例があります」と伝えることもできます。これがプロンプトエンジニアリングによる改善方法です。2つ目の技術は、Retrieval Augmented Generation、通称RAGです。RAGは、あなたの文書と対話することです。ここでは、モデルが学習した情報を活用するのではなく、モデルを使用してあなた自身のドキュメントについての質問を要約し、回答します。これは素晴らしい方法です。なぜなら、学習データではなく自分のデータを使用するため、幻覚（hallucination）を大幅に減らすことができるからです。
別の例を見てみましょう。先ほどと同じプロンプトを使用し、質問に答える前にブランドガイドラインを確認するようモデルに指示します。答えは「Wholesome Snacking, Naturally」になります。「naturally」という言葉がブランドガイドラインに出てくるため、モデルはこの答えを提供します。また、この情報がブランドガイドラインの20ページからのものであることも示されます。これにより、ユーザーは必要に応じて確認したり、さらに読んだりすることができるため、信頼性が高まります。
では、これを実践に移す方法を見てみましょう。アーキテクチャ図をお見せします。ステップ1は、テキストをベクトルに変換することです。ベクトルは、単語の意味的な意味を捉えたテキストの数値表現です。これらは3Dデータベース、この場合はAmazon OpenSearchに保存されます。これが私たちのベクトルデータベースです。これは最初に、開始前に一度だけ行います。ドキュメントが変更されたり、新しいドキュメントを追加したりする場合は、繰り返す必要があります。
ユーザーがWebアプリケーションと対話してクエリを送信すると、クエリはAPI Gatewayに送られ、Lambda関数をトリガーします。Lambda関数はその質問を受け取り、Amazon Bedrockの埋め込みモデル（CohereやTitanモデルなど）を使用してベクトルに変換します。応答が返され、ベクトルデータベースに送られます。Amazon OpenSearchは、その質問の答えがある段落を返し、それらの段落と質問がテキストモデルに送られます。テキストモデルは答えを生成し、その答えがユーザーに返されます。これがRAGの実装方法です。
LLMの性能向上戦略：Fine-tuningと再トレーニング
Large Language Models (LLMs) を実装するための次の戦略は、fine-tuning です。プロンプトエンジニアリングと RAG を行ったけれども、まだ足りないと感じたとしましょう。ブランドガイドラインを参照せずに、自社のスタイルや専門用語、トーンで話すようにモデルに求めたい場合はどうすればいいでしょうか？ そんな時に使うのが fine-tuning です。また、特定のタスクを本当に改善したい場合にも fine-tuning を使用します。
以前と同じプロンプトを使用した例を見てみましょう。答えは「Simply fruit and grains, simply delicious」です。なぜモデルは「simply」という言葉を使っているのでしょうか？ それは、このモデルに過去のプレスリリースや CEO のスピーチを学習させ、会社特有の言葉遣いやスタイルを習得させたからです。Fine-tuning は、既存の AI モデルを現在のタスクに特化したデータで訓練し、パフォーマンスを向上させる強力な技術です。
このプロセスは、過去のプレスリリース、CEO のスピーチ、新入社員向けのオンボーディング情報、過去のマーケティング資料などを使って行うことができます。モデルは、特定のコンテキストに最適な言葉遣いや話し方を学習します。
Amazon Bedrock で fine-tuning を実装するプロセスは簡単です。まず、データを S3 バケットに入れます。次に、Titan、Cohere、Llama 2、そして近々 Anthropic モデルなどのベースモデルを選択します。 新しいバージョンのモデルを生成するには数時間かかります。 Fine-tuning されたモデルができあがったら、プロンプトで使い始めることができます。
先ほどお見せしたアーキテクチャを使用し、ベースモデルの代わりに この fine-tuning されたモデルを使用するだけです。アーキテクチャは同じままで、Bedrock の API 呼び出しでモデル名を変更するだけです。この簡便さにより、将来的に同じ API で名前を変更するだけで、モデルを簡単に切り替えることができます。
最後に説明する戦略は再トレーニングです。fine-tuningは数百または数十の文書に対して効果的ですが、数千の文書を扱う場合は再トレーニングが必要になります。例を挙げてみましょう。ソーシャルメディアの投稿を書くように求めるプロンプトを考えてみてください。トレーニングやRAG、プロンプトエンジニアリングを行わない場合、基本的なモデルは「オーツ麦を使用した新しいグラノーラバーを発売しました。詳細はこちら」といった回答をするかもしれません。しかし、再トレーニングされたバージョンでは、はるかに良い結果が得られます：「新発売のブルーベリーブラストグラノーラバー。ジューシーなブルーベリーとサクサクのオーツ麦がぎっしり。これらのバーはカリッとしていて美味しく、高品質の原材料で作られています。」
再トレーニングされたモデルは、サプライチェーンの追跡、倫理的な農家との協力、持続可能な活動への注力に関する情報を学習しているため、高品質の原材料について知っています。また、以前のマーケティングキャンペーンから、ブランドがカリカリしたバーを誇りにしていることを認識しています。その結果、追加のプロンプトなしで、会社のスタイル、トーンおよびブランディングに沿ったコンテンツを自動的に生成します。
このような再トレーニングを実施するには、データサイエンスのスキルと、当社のデータサイエンスサービスであるAmazon SageMakerという別のツールが必要になります。プロセスはfine-tuningと似ています。Llama 2 や他のオープンソースモデルなどの事前トレーニング済みの基盤モデルを取り、SageMaker内のツールを使用して数千の例を適用し、その後、同じRAGアーキテクチャで使用できる再トレーニング済みモデルを得ます。
これらの技術は相互に排他的ではないことに注意することが重要です。最高のパフォーマンスを得るために、これらを組み合わせることができます。一部の顧客は自分でfine-tuningを行いたいと考えるかもしれません。LoRAやQLoRAなどのパラメーター効率の良いfine-tuning（PEFT）技術に興味がある方は、SageMakerでも実行できます。今週は、SageMakerでfine-tuningを行う方法に関する他のセッションもありますので、これらの技術についてより深く掘り下げたい方は、ぜひ参加してください。
Generative AI実装のためのガイダンスとまとめ
まとめると、プロンプトエンジニアリング、RAG、fine-tuning、再トレーニングの4つの技術があります。これらは排他的ではなく、組み合わせて使用できることを覚えておいてください。すべてを一度に習得しようと心配する必要はありません。最初の2つか3つで要件の90%をカバーできるでしょう。
さて、私の経験に基づいて、これらのテクニックの実装を始めるためのガイダンスをお伝えしましょう。 まず、これらのモデルに慣れ親しんでください。実際に試してみて、どのように反応するか、何が得意なのか、どのように機能するのかを体感してください。次に、適切なユースケースを見つけてください。単なる「うまくいくかどうか見てみよう」という実験ではなく、チームや会社の実際の問題を解決するものを選びましょう。 ビジネスインパクトを生み出し、目に見える形のユースケースを探してください。そうすることで、それをショーケースとして活用し、本番環境に移行するために必要な資金を確保できます。
次に、プロトタイプを構築しますが、エンドツーエンドの視点で行ってください。 モデルができることだけに焦点を当てるのではなく、ユーザーの視点からどのように見えるかを考えてください。このツールを誰が使用するのでしょうか？プロトタイプを構築し、常にユーザー体験から始めて、エンドツーエンドで見てください。
このプロセスを簡単にするために、Amazon Bedrockを使用できます。6つの異なるモデルにアクセスするには、APIコールほど簡単な方法はありません。 さらに、これらのモデルの異なるサイズも利用できます。また、コードリポジトリやPartyRockも提供しており、これらのモデルと対話するための多くの方法があります。
最後に、本当に自分でこれを構築したいのか、それともShowpadのような営業チーム向けの既製のソリューションを活用できるのかを検討してください。このプロセスを経ることで、これが適切なツールやユースケースであるかどうかについて、より情報に基づいた決定を下すことができるでしょう。
このセッションに参加していただき、ありがとうございました。お役に立てたなら幸いです。特に一日の終わりに近い時間帯にもかかわらず、ご注目いただき感謝しています。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion