re:Invent 2023: AWSとUnited AirlinesによるAmazon Bedrockを用いたAI導入事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Accelerate generative AI application development with Amazon Bedrock (AIM337)
この動画では、Amazon Bedrockを活用したgenerative AIの実践的な導入方法を学べます。AWSのMark RoyとGirish Arunagiriが、knowledge base、agents、ファインチューニングなどの機能を具体的なユースケースと共に解説します。さらに、United AirlinesのSanjay Nairが、Bedrockを用いた実際の導入事例や、責任あるAI、セキュリティ、コスト最適化への取り組みを紹介します。最新のAI技術を企業に導入する際の課題と解決策が詰まった貴重なセッションです。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon Bedrockの紹介と本セッションの概要
みなさん、こんにちは。re:Inventの3日目の午後、いかがお過ごしですか？まだ元気は残っていますか？素晴らしい、この会場は活気に満ちていますね。今年最もホットな話題について話せることを、とてもワクワクしています。なぜこんなにホットなのでしょうか？私の意見では、これは本当にゲームチェンジャーだからです。世界中のビルダーたちが、generative AIを使って全く新しい体験を生み出し、また、これまで不可能だったり、コストがかかりすぎたり、複雑すぎたり、時間がかかりすぎたりして取り組めなかった問題に挑戦しているのを目にしています。foundation modelsを使うことで、それらを実現できるようになったのです。
今日は、Amazon Bedrockについてお話しするのを楽しみにしています。Bedrockがどのようにして皆さんの journey を加速し、 より迅速に、安全に、そして選択肢を持ってgenerative AIを活用するお手伝いができるかについて、詳しくお話ししていきます。私の名前はMark Royです。AWSのprincipal ML architectで、Amazon Bedrockのlead solution architectを務めています。とてもエキサイティングな経験です。AWSに6年間在籍し、何百もの企業と協力して大規模なMLの実践に取り組んできました。今年は24時間365日Amazon Bedrockに没頭しています。40年間のビルド経験がありますが、これまで多くのクールなプロジェクトに携わってきましたが、これは私が今まで取り組んだ中で最も魅力的なものです。
エンタープライズ規模でのGenerative AIの実現に向けた課題
私の後に話をするML specialistのGirish Arunagiriと、BedrockをどのようにUnitedで使用しているかについて話すUnited AirlinesのSanjay Nairと一緒にここにいます。実際のアジェンダに入る前に、少し議論の枠組みを設定させてください。Girishとはこのセッションのために数週間前に準備をしていた時、人々は何を知る必要があるのかを考えていました。おそらく皆さんはこの時点でBedrockについて飽きるほど聞いているかもしれません。もしかしたらそうでもないかもしれません。火曜日にはAdamから素晴らしいkeynoteを聞き、今日もSwamiから素晴らしいkeynoteを聞き、Bedrockに関する大量の発表がありました。
私たちが決めたのは、他のセッションでは得られない、全てを結びつける部分です。ここにいる皆さんの多くは、どうやって始めればいいのか、Bedrockのこれらの機能を全て活用するにはどうすればいいのか、計画を立てようとしているかもしれません。そこで、このセッションでは主にそれについてお話ししていきます。今年私たちが行った何百もの会話の中で見られるシナリオを説明させてください。
エンタープライズ規模でgenerative AIをどのように実現するか考えようとしている自分を想像してみてください。そして、あなたは非常に大きな会社で働いています。複数の事業部門があり、何十ものチームがものを作ろうとしており、generative AIのバックログには何百もの使用例があります。Amazonでは、顧客の要件から逆算して考えるのが好きです。では、これらの顧客から何を聞いてきたでしょうか？
顧客が求めるGenerative AI機能とAmazon Bedrockの特徴
まず第一に、私にはスケールが必要です。小規模なスケールで素早くプロトタイプを作成し、その後大規模なスケールでそれを本番環境に投入し、これらのアプリケーションに対して大量のスループットを提供する必要があります。第二に、特定のモデルに縛られたくありません。一つのユースケースで複数のモデルが必要になるかもしれません。 今週末に、聞いたこともないベンダーから全く新しいモデルが登場するかもしれません。ですから、モデルの選択肢が欲しいのです。これらのモデルは変化し、それも非常に速いペースで起こるでしょう。すでにその兆候が見えています。ですので、ラスベガスにいる間に、新しいモデルが登場し、より速く、より優れ、より安価になるという賭けをしてみるのもいいかもしれませんね。
三つ目は、検索拡張生成（Retrieve Augmented Generation）です。RAGについてはご存知かもしれません。これは、企業のデータをGenerative AIと結びつけるものです。 お客様から聞いているのは、これをより簡単にしてほしいということです。当たり前のように使えるようにし、アプリケーションに簡単に組み込んで、文書やデータにアクセスできるようにすることで、差別化を図れるようにしてほしいのです。次に、多くの場合、ベースモデルとプロンプトエンジニアリング、そしてRAGだけでは不十分です。行き詰まり、必要な精度が得られません。大勢のPhDを雇わなくても、簡単にカスタマイズできるようにしたいのです。
他にも耳にしているのは、Generative AIを使って自動化やシステム統合を効率化する手助けが欲しいということです。そして最後に、すべてが人間が可能な限り安全で、完全なデータプライバシーを備え、モデルプロバイダーとのデータ共有を行わず、AWSサービスに期待されるすべてのセキュリティを備えている必要があります。これらが、私たちがAmazon Bedrockで市場にもたらしたものであり、今日お話しする内容です。
セッションのアジェンダと架空の金融サービス企業Octank Financialの設定
では、アジェンダをご紹介します。これから15分間、Girishがユースケースについて説明します。その後、Bedrockの実際の動作をライブデモでご覧いただきます。続いて、Sanjayが登壇し、BedrockがUnited Airlinesの取り組みにどのように役立っているかについてお話しします。そして最後にまとめを行います。
ユースケースに入る前に、ここで状況設定をさせてください。皆さんは全員、Octank Financialに雇われたとします。これは架空ですが非常に大規模な金融サービス企業で、複数の事業部門を持っています。投資管理、退職サービス、保険など多岐にわたる事業を展開しています。数十のチームがあり、少なくとも500のユースケースが準備されています。
これから、最も一般的な3つのgenerative AIタスクを見ていきます。そして、Girishがそれぞれのユースケースについて説明します。彼は、Bedrockのさまざまな要素がどのようにしてこれらのタスクをより速く、より良く実現するのかを明確に示します。それでは、Girishに引き継ぎます。
質問応答ユースケースとAmazon Bedrockのknowledge baseとagents機能
ありがとうございます。皆さん、こんにちは。皆さんはOctank Financialの方々で、私はAmazon Bedrockを使ったgenerative AIの導入についてのストラテジーコンサルタントとしてここにいます。今日最初に見ていくユースケースは、質問応答です。私たちは皆、質問を持っており、答えを求めています。 その答えは、質問が参照している分野において正確でなければなりません。Octank Financialには何十万もの文書があります。これらは、ポリシーマニュアル、目論見書、私募記録などかもしれません。お客様は、あなたがたのデータや文書と対話し、正確な回答を得たいと考えています。彼らは、generative AI基盤モデルが正しいと思う答えを求めているわけではありません。そして、Octank Financialの皆さんは、正しい答えを提供したいと考えています。
どのようにしてそれを実現するのでしょうか？それには、ナレッジベースと呼ばれるものを構築します。ナレッジベースは、基本的に文書アーカイブから文書を取り込むことで構築されます。この文書アーカイブは、実際にはどのようなデータでも構いません。今回の場合、文書アーカイブを考えています。すべての文書を取り込み、Amazon Bedrockのナレッジベース用のingest APIを呼び出します。ナレッジベースとは何でしょうか？ナレッジベースは2つの要素の組み合わせです。 1つは埋め込みモデルで、もう1つは、ナレッジベースに取り込んだすべての文書から作成した埋め込みを格納するベクトルストアです。
なぜナレッジベースを使用すべきなのでしょうか？ナレッジベースには、ナレッジベースに投入するデータを自動的にチャンク分割するのに役立つインテリジェンスが組み込まれています。チャンクとは何を意味するのでしょうか？ 例えば、100ページのPDF文書があるとします。ナレッジベースには、非常に効率的なベクトルを作成するための適切なチャンクサイズを識別するインテリジェンスがあります。そして、そのチャンクを埋め込みモデルに送ります。この場合、Amazon Titan Text Embeddingsの使用をお勧めします。Titan Text Embeddingsを使用してベクトルを作成し、選択したベクトルストアに格納します。これで、すべての文書がベクトルとして準備完了の状態になりました。
このナレッジストアとの2種類のインタラクションを見ていきましょう。 1つ目は、お客様がウェブサイトに組み込まれたチャットボットを通じてアクセスする場合です。 彼らが質問をします。例えば、特定の証券について出した取引注文をキャンセルしたいと考えているとします。
取引はまだ実行されていませんが、彼らの質問は「この取引をキャンセルしたいのですが、まだキャンセルする資格はありますか？」というものです。つまり、クエリがknowledge baseに入り、キャンセルポリシーを調べ、その情報を顧客に返す必要があります。しかし、その情報を顧客に返す前に、language modelに送信して、返ってきたすべての検索結果に関連するテキストを生成し、その情報やcompletionを顧客に送り返します。これがchatbotの体験です。
同時に、support associateがsupport portalに座っており、顧客が取引をキャンセルして料金が請求されないようにしたいという情報を受け取ります。彼女は、ポリシーが顧客の取引キャンセルを許可しているかどうかを確認したいと考えます。彼女はAmazon Bedrockのagentsと呼ばれるものを使用します。この場合、order support agentと呼んでいます。彼女はknowledge baseにクエリを送信し、ポリシーを尋ねます。ポリシーが返ってきて、取引はまだ実行されていないので、キャンセルしても問題ないと言います。彼女は単に「注文をキャンセルし、返金を処理する」という指示を出します。
この時点で、agentはAPI呼び出しを介してorders databaseにクエリを送信します。orders databaseはまだ保留中の注文を返し、agentに戻します。次のアクションとして注文をキャンセルし、その情報をsupport personnelに送り返します。このスライドには強調したい2つの機能があります。1つはknowledge baseで、もう1つはagentsです。knowledge baseとは何か見てみましょう。knowledge baseは、foundation modelsを安全に企業のデータに接続するのに役立ちます。企業のデータをfoundation modelに直接アクセスさせたくはありません。データを安全に保つことが第一です。
これは、応答の正確性を向上させるのに役立ちます。なぜなら、パブリックドメインから学習したことから応答を提供するのではなく、その呼び出しの一部として提供したデータのみを参照して応答を返すからです。データの自動取り込みに関して、RAGを簡単に実装する方法を提供します。必要なprompt augmentationも行えます。例えば、プロンプトが単に「注文をキャンセルしたい」だけの場合でも、モデルやバックエンドシステムがこの「私」が誰なのかを理解する必要があれば、顧客としての私に関する追加のメタデータを渡す必要があります。これがそこで行うprompt augmentationです。
もちろん、knowledge baseから必要な検索を行うのも非常に簡単です。そして最も重要なのは、多くの顧客が「これらの回答はすべて良いのですが、ユーザーは本当にこれらの回答がどこから来ているのかを知る必要がある」と言っていることです。citationは、適用可能な場合、knowledge base統合を通じて自動的に利用できます。agentsは、このユースケースの一部として取り上げたい次の機能です。簡単に言えば、agentsはあなたに代わってタスクを計画し実行するのに役立ちます。顧客からの質問やクエリを受け取り、それを分解し、基本的にあなたに代わってタスクのパイプラインを作成します。
そして、モデルが様々なデータセットにAPIコールを通じて安全に接続できるよう支援します。Agents for Amazon Bedrockを通じて、あなたに代わって安全にAPIコールを行います。最後に、エージェントがあなたに代わって多くのアクションを実行しました。それをブラックボックスにしたくないですよね。どうすればいいでしょうか？エージェントはトレース機能を提供しており、これを使ってトラブルシューティングができます。このエージェントがこのアクションを完了するために取った様々なステップについて質問がある場合、Agents for Amazon Bedrockのトレース機能を使ってインタラクションをトラブルシューティングできます。これがAgents for Amazon Bedrockです。
文書要約ユースケースとAmazon Bedrockのバッチ処理機能
さて、Q&Aのパートが終わったので、2つ目のユースケースに移りましょう。 ここで取り上げる2つ目のユースケースは、文書要約です。皆さんはOctank Financialの一員です。Octankにはリサーチ部門があり、何百人もの調査アナリストが日々何千もの株式を追跡しています。多くの文書が入ってきます。決算発表の報告書、ESGスコア、その他様々なものです。彼らには処理すべき多くの文書があります。それらを読み、ポートフォリオマネージャーに研究結果を提供し、ポートフォリオの決定（買い、売り、保有など）を行うためです。要約して文書要約DBと呼ぶものに保存する必要がある大量の文書があります。これがユースケースです。
どのように行うのでしょうか？この場合、ビルダーは厳選されたテストスイートを作成し、プロンプトを作成するために使用できる事前に検証された要約にアクセスできます。彼女はプロンプトエンジニアリングを使用してモデルの動作をテストします。この場合、彼女はClaudeについて多くの良い評判を聞いています。ちなみに、Claude 2.1が昨日発表されました。今日から利用可能で、かなり安くなっています。GPT-4 Turboより約20%安いです。それだけお伝えしておきたかったのです。ビルダーが来て、プロンプトエンジニアリングを行います。彼女はClaudeについて良い評判を聞いています。データとプロンプトをClaudeに送ります。プロンプトは単に「この文書を要約してください」というものかもしれません。
彼女は文書を送り、応答を見て、「よし、いいね」と思います。しかし、もっと早く、安く、レイテンシーを下げ、コストを下げてできないかと考えます。そこで、Claude Instantについても良い評判を聞いています。同じプロンプトと同じデータセットをClaude Instantに送ります。これはすべて同じAPI、BedrockのinvokeAPIを通じて行われます。出力を得て、両方の出力を昨日発表したモデル評価機能に送ります。比較を行い、彼女が発見したのは、確かにinstantの方が速くて安いということです。しかし、彼女はより高い精度を求めています。なぜなら、金融の決定を行っているからです。要約は文書の内容を正確に反映する必要があります。それに関しては近道はありません。そのため、彼女は大きなClaudeモデルを選択します。
POCから本番環境に移行する最初のステップは、バックフィルを行うことです。彼女は文書リポジトリに約50万件の文書を持っています。すべての文書を取り出し、非常にシンプルに言えば、Amazon Bedrockのバッチ処理を通す必要があります。これは公開発表ではなかったと思いますが、今日から利用可能になり、文書リポジトリからすべての文書を取り出し、モデルパイプラインを通す非同期ジョブを実行するのに役立ちます。この場合、先ほど言ったように、Claudeを使用します。プレミアムモデルのClaudeを使用し、出力をS3バケットに書き込み、S3バケットからデータを文書要約DBに入れます。これで彼女の準備は整いました。
彼女は仕事を終え、宿題を済ませ、POCを完了し、リポジトリから50万件のドキュメントを全てロードしました。私たちは皆、これらのドキュメントが毎分、毎時間到着することを知っています。どうすればいいでしょうか？イベント駆動型のパイプラインを設定します。これはS3トリガーです。ドキュメントがS3に到着すると、step functionが呼び出されます。Amazon Bedrockを通じたstep functionのネイティブ統合が月曜日に発表されました。step functionはAmazon Bedrockのinvoke model APIを呼び出します。ドキュメントをClaudeに送信し、Claudeはドキュメントの簡単な要約を作成し、あなたが構築したドキュメント要約DBに書き込みます。これで、膨大な量のドキュメントを読む必要のない、とても幸せなリサーチアナリストが誕生します。
エンティティ抽出ユースケースとファインチューニング機能
彼女はすべてのドキュメントの簡単な要約を手に入れました。要約が興味深いものであれば、ドキュメントを詳しく見て、さらなるアクションを取ることができます。ドキュメント要約。これは、MarkとI私が話すほぼすべての顧客で見られることです。ドキュメント要約の取り組みです。
先ほど述べたように、Amazon Bedrockのバッチ処理は、大量のデータに対して推論を実行するのに役立ちます。サービス上の他のトラフィックによってスロットリングされることはありません。本質的に、あなたのワークロードを非同期で実行し、より速くジョブを完了させます。スロットリングはありませんが、非同期なので、1、2秒で結果が返ってくることはありません。セットアップして、都合の良い時間にスケジュールを設定できます。通常、ユースケースがサポートしている場合、バックフィルジョブや夜間プロセスに使用します。
Amazon Bedrockのバッチは、完全に管理されたモデル呼び出しジョブです。失敗やリスタートを処理するコードを書く必要はありません。最も重要なのは、私たちから直接提供されるベースモデルであれ、Bedrockで微調整することを選択したカスタムモデルであれ、APIは同じだということです。バッチ処理は両方のタイプのモデルと推論タイプで機能します。
では、3つ目のユースケース、エンティティ抽出に移りましょう。世界中に何百万人もの顧客を持つOctank Financialという会社を考えてみましょう。彼らは注文のキャンセル、新規口座開設、月次明細書の請求など、さまざまなトピックに関するメールを受け取っています。最近、Octank Financialは顧客への応答時間が悪化傾向にあることに気づきました。これに対処するため、彼らはAIを導入してメールを読み取り、エンティティを抽出したいと考えています。
エンティティ抽出の本番パイプラインとファインチューニングの利点
エンティティとは、顧客のアカウント番号、株式銘柄、都市、住所、またはメールから機械学習モデルが抽出する必要のあるその他の関連情報を指します。目標は、これらのエンティティを抽出し、さらなるアクションのためにデータベースに保存することです。可能なアクションの一つをご紹介しましょう。
ビルダーは、キュレーションされたテストスイートとラベル付けされた事前検証済みのメールにアクセスできます。彼女はプロンプトエンジニアリングを行い、最近利用可能になったLlama 2を試すことにしました。130億パラメータのバージョンは約2週間前に利用可能になり、700億パラメータのバージョンは今日早くに発表されました。Llama 2でプロンプトエンジニアリングを行った結果、精度は約80%であることがわかりました。これは、Llama 2がパブリックデータセットで学習されているのに対し、彼女はOctank Financialのドメイン固有のデータを扱っているためです。
精度を向上させるため、彼女はモデルのファインチューニングを選択しました。Llama 2のファインチューニングバージョンを作成し、モデル評価に送ります。評価の結果、精度が約90%に向上したことがわかりました。これで彼女は本番環境に移行する準備が整いました。
本番パイプラインの仕組みは次のとおりです：サーバーからメールが届き、エージェントに送られます。エージェントはペイロードを処理し、ファインチューニングされたLlama 2モデルに送ります。Llama 2はエンティティ抽出を行い、自動応答を作成します。エージェントは、自動応答の信頼度が85%を超えていれば、その応答を顧客に送り返します。そうでない場合、メールはサポートチームのキューに送られます。人間が支援付きの応答を作成し、顧客に送り返すことで、サポートチームに送られるメールの量を減らすことができます。
ここでファインチューニングについて触れたいと思います。 ファインチューニングは、自社のデータを提供することで、foundation modelの精度を最大化するのに役立ちます。Amazon Bedrockで、Llama 2、Command、Titan Foundation modelのファインチューニングが利用可能になったことを発表しました。ベースモデルとカスタムモデルの両方に同じAPIを使用して、バッチ処理と同じようにファインチューニングされたモデルにアクセスできます。
Amazon Bedrockのデモンストレーション：モデル選択とknowledge base
ファインチューニングされたモデルは、ベースモデルと同じように使用できます。3つのユースケースすべてで気づいたかもしれない共通点は、モデルの選択です。現在、Amazon Bedrock には Amazon を含む6つのモデルプロバイダーがあり、十数個のモデルを提供しています。Amazon Bedrock で利用可能なモデルプロバイダーとモデルの数は、今後確実に増えていくでしょう。Octank Financial の IT リーダーやビジネスリーダーとして、単一のプラットフォーム上で複数のユースケースをサポートできます。それが、generative AI のための Amazon Bedrock です。では、Mark に簡単なデモをお願いします。
ありがとうございます。では、デモマシンに再度ログインしましょう。そして、大きな緑色の「demo」ボタンを押します。ちゃんと「demo」と書いてありますね。おっ、うまくいきました。素晴らしい。ここでは3つか4つのデモをお見せします。時間を見ながら進めていきましょう。Bedrock について話すとき、私たちが繰り返し強調しているのは「モデル選択」という概念です。ここでそれを簡単に紹介したいと思います。まず、プロンプトを入力してみましょう：「アメリカ合衆国の初代大統領は誰ですか？」皆さん、ご存知ですよね？
ここでEnterキーを押すと、まず Bedrock を使って Streamlit アプリを生成しました。というのも、私はユーザーインターフェースを作るのが得意ではないからです。そして、そのアププリでEnterキーを押すと、利用可能なすべてのテキストモデルのモデル ID のリストに対して複数のスレッドを生成し、並列で各モデルに送信します。ここに Cohere Command があります。かなり長い回答ですね。ここでプロンプトチューニングができそうです。そして、Claude、Claude Instant、Claude V2.1 もあります。Titan Text、Light と Express、Jurassic 2 Ultra と Mid、そして Llama 13b と Llama 70b もあります。
コードを簡単に見てみましょう。ここにモデル識別子のリストがあります。これらはコンソールから取得できますし、Bedrock で利用可能な foundation model をリストアップする API もあります。そして、ここに Bedrock モデルを呼び出す簡単なコードがあります。これは、Enterキーを押したときに生成される各スレッドから呼び出されます。モデル識別子を使用し、プロンプトを渡し、返すトークン数、temperature などを指定しています。
つまり、1つの API で複数のモデルを使用でき、これらは時間とともに進化し、より良く、より速くなり、プロバイダーやモデルも増えていくでしょう。企業全体が一連のモデルを活用でき、各モデルに対して別々のインフラを学ぶ必要がないというのが狙いです。そして、完全マネージド型なので、各モデルを最適にホストする複雑さを心配する必要もありません。大規模言語モデルのホスティングを試したことがある方なら、なぜ「大規模」言語モデルと呼ばれるのかがわかるでしょう。そこにはかなりの作業が必要なのです。さて、モデル選択のデモはこれくらいにして、次は knowledge base に移りましょう。
Amazon Bedrockのagents機能のデモンストレーション
Girishがknowledge basesについて多く語っていましたね。それらが実際にどう機能するか見てみましょう。ここで使用するモデルを選択します。そして、小さなクエリを入力しますが、何をしているか説明しますね。knowledge baseの名前からわかるように、これは質問応答用の税務knowledge baseです。50ほどのIRS（米国内国歳入庁）の出版物をダウンロードしました。それぞれ5ページ、10ページ、25ページほどの文書です。今、処理中です。これがライブデモを行う際の結果ですね。retrieval APIを使用しているところです。はい、re:Inventはとても混んでいますね。
knowledge baseにクエリを送信するAPIを呼び出しました。そのknowledge baseに関連付けられたembeddingsモデルを使用し、チャンク化、ベクトル化、保存したすべての文書に対してベクターストアで類似性検索を行います。これらすべてを、1行のコードも書かずに実行しています。knowledge baseはウィザードを通じて作成しました。コマンドラインやAPIを通じて行うこともできます。完全に管理され、foundation modelを選び、ベクターストアを選び、文書を指定するだけで利用可能になります。このAPIを使えば、好みの言語モデルを組み込んで質問をすることができます。
もう一つの機能をお見せしましょう。言語モデルを使用する必要はありません。別の質問をしてみましょう。「通勤のためのオイル交換は控除できますか？」できるだけ多くの - 結果が返ってくる速さがわかりましたか？これは直接検索を使用しているだけです。柔軟性があります。質問に一致するチャンクを取得するだけでなく、LLMを呼び出して親切な回答を得ることもできます。直接検索を使用した場合の速さがわかります。個々の結果にアクセスでき、ソース文書も開くことができます。
以上がknowledge basesでした。次はagentに移りましょう。これは、Adamのkeynoteで火曜日に一般提供が開始された最も素晴らしい新機能の1つです。ここにはcustomer relationship management botがあります。Salesforceやその他のシステムで顧客情報を管理し、活動や機会、顧客に関連するその他の事項を追跡しているかもしれません。ここでは、アカウントマネージャーや営業チームを支援しようとしています。利用可能なAPIをラップしたbotがあります。
近々、おそらく来週会う予定の顧客とのミーティングを提案するよう依頼してみます。複数の顧客と仕事をしているので、各顧客の状況をすべて把握するのは難しいです。そこで、agentを使って状況を把握しようとしています。agentはいくつかのAPIを知っています。あれ、何か問題があったようです。もう一度試してみましょう。最近の interactions with...十分な情報がないと判断したようです。別のものを試してみましょう。これも機能しませんね。もう一度試してみます。
はい、少し良くなりましたね。右側に、Girishが話していたトレースを表示しています。これは、利用可能な様々なアクションを呼び出したものです。このプランが作成されます。リクエストを受け取り、どのようなアクションが利用可能か、どのような知識が利用可能かを把握します。そして動的にプランを立て、どのアクションを呼び出すべきか、どの順序で実行すべきか、さらには反復処理までも決定します。ここで興味深いのは、利用可能だった「最近のやり取りを一覧表示する」APIを呼び出したことです。これにより、最近の一連のミーティングが検索されました。
United AirlinesのSanjay Nairによる導入と企業の使命
例えば、この日に会議を行い、こんなメモがありました。彼らは私たちの製品SmartShipに興味を持っているようですが、予算削減についても話し合っています。さらに以前の会議では、私たちの信頼性について不満を持っていたようです。エージェントはどうしたでしょうか？この情報を受け取り、こう判断しました。「SmartShipについての会議を開きましょう。新製品のデモを行い、価格を見直し、タイムラインについて話し合い、信頼性についても検討しましょう」。このようにして、私のためにアジェンダを作成してくれました。さらに、この顧客が水曜日の午後に会議を好むことを知っていたので、会議の時間まで提案してくれました。これが結果です。
さて、次は何が待っているでしょうか。エージェントコンソールについても少しお見せしましょう。先ほどはエージェントAPIを使用しましたが、同じエージェントがコンソールからも利用できます。
コンソールを通じてもテストできますし、バージョン管理やエイリアスの設定もできるので、非常に柔軟性があります。編集可能な最新の作業ドラフトがあります。エージェントに提供するものの1つに、一連の指示があります。ここでは「あなたはカスタマーリレーションシップマネジメントエージェントです。その顧客の状況を理解するのを手伝います」というように指示しています。
また、利用可能なアクションのセットも設定しました。アクションを利用可能にする際には、スキーマを提供する必要があります。つまり、やり取りの名前、APIの名前、その説明、入力パラメータ、出力パラメータを指定します。これによって、エージェントは何をすべきか、どのような順序で行うべきかを理解できるのです。エージェントは生成AIを使用して動的にプランを立て、それを実行します。
もう一つ簡単にお見せしたいのは、 アクションがLambdaを使って実装されているということです。Lambdaを使っている方はいますか？数人の手が挙がりましたね。Lambdaの関数は非常に単純です。基本的には、どのような呼び出しが来ているかを判断する簡単なディスパッチャーを書くだけです。 そして、それを実行します。ここに私が用意したダミー関数がありますが、これはミーティングのセットを返すものです。実際の実装では、Salesforce APIを呼び出してそのデータを検索し、返すことになります。そして、LLMのパワーを使って、計画を実行したり立てたりするだけでなく、結果を処理して興味深いことを行うのです。
さて、ここでUnitedのSanjayの話を聞く時間になりました。ありがとう、Mark。皆さん、こんにちは。改めまして、United AirlinesのSanjay Nairです。 私は当社のデータAIおよび分析エンジニアリングを統括しています。私の役割は、生成AIで作成されたOctank bankのシナリオから、世界最大の航空会社の一つである実際の顧客の視点へと皆さんを導くことです。そして、MarkとGirishが説明した Amazon Bedrock の製品と技術に基づいてストーリーを展開していきます。
United AirlinesにおけるGenerative AI戦略とAmazon Bedrockの採用
まず、チームの簡単な紹介から始め、今年直面した課題と機会について話し、AWSなどの戦略的パートナーと協力してどのように戦略を立て、設計し、ソリューションを実装したかを説明します。そして、Bedrockを使用して生成AIの膨大な可能性をどのように解き放つことができるかという今後の道筋について話します。United Airlinesの使命は、航空業界で最高の航空会社になることです。 これは単に規模や路線網、就航先の数、あるいは輸送する顧客数において最高の航空会社になるということだけではありません。最高の顧客体験を提供し、最高の顧客ロイヤルティを実現し、従業員の積極的な参加を促すことを意味しています。
私たちのストーリーで本当に興奮するのは、今後数年間で700機以上の航空機を私たちの機体に追加するという成長戦略です。これは私たちの機体をほぼ倍増させることですが、「good leads the way（善が道を導く）」というモットーで呼んでいる方法で行います。これは、私たちが特権的に奉仕するコミュニティのために良いことを行い、私たちの航空機に乗る顧客に正しく対応することを意味しています。 私たちは複雑なビジネスを展開していますが、United では、AIとML、特に生成AIが、ネットワーク運用、機内サービス、フライト運航、収益管理、あるいはビジネスの商業面など、ビジネスの多くの異なる領域で大きな付加価値をもたらすと考えています。
私のチームは、企業全体をサポートする特権を持っています。私たちは、運用、商業、デジタル、そしてそれ以外の分野で大きな価値を付加すると信じている生成AIプラットフォームを実装しています。
2023年が始まった時点で、ここにいる企業のほとんどが、generative AIに関する計画を持っていなかったと言っても過言ではありません。私たちが計画を立てたというよりも、generative AIが私たちを襲ったというのが実情でした。しかし、私たち全員が素早く対応しなければなりませんでした。Unitedでは、多くのベンダーやパートナーが企業全体のビジネスユーザーに接触し、すべての問題を解決すると約束するソリューションを提供していたため、迅速な対応が求められました。generative AIには大きな可能性があることは認識していましたが、同時にこの新しい技術にはリスクや落とし穴もあることを理解していました。
このプログラムの戦略を立てるために、いくつかの指針を設定しました。まず、「包括性によって推進されるイノベーション」と呼ぶ、すべてのビジネスユーザーのアイデアに耳を傾けることを重視しました。すべてのユースケースを検討し、generative AIに適したものを選択するための適切なアプローチを確立したかったのです。次に、他のパートナーやベンダーが約束していたように、迅速な市場投入が必要でした。そして、同じく約束されていた簡単で迅速な統合を実現する必要がありました。
では、私たちは何をしたのでしょうか？AWSを含む戦略的パートナー数社と協力し、誇大宣伝と現実を区別する手助けを求めました。AWSは、私たちのデジタル技術プラットフォームをクラウドへ近代化するための戦略的パートナーです。そこで、Amazon Bedrockを最初にプレビューする企業の1つとして紹介されました。Bedrockについて、私たちを納得させた特徴がいくつかあります。まず、完全に管理されたAWSサービスであることです。これは、既存のAWSプラットフォーム上に構築されているため素晴らしいポイントです。次に、APIを呼び出すフレームワークで動作するため、ビジネスユーザーやアプリケーション開発パートナーが非常に使いやすいという点です。そして最も重要なのは、私たちが本当に必要としていたモデルの選択肢を提供してくれたことです。
この分野がまだ初期段階にあり、多くの未知の要素があることは皆が理解していました。そのため、実験や試行錯誤ができる選択肢が必要でした。そうすることで、各ユースケースに最適なモデルを決定できるのです。さらに、企業全体にポイントソリューションが散在すると、セキュリティや責任あるAIの管理が悪夢になりかねません。そのため、この一連の取り組みを推進するための集中管理された運用を確保したいと考えました。
すでにセキュリティについて触れましたが、大企業にとってセキュリティは非常に重要です。そのため、Bedrockにプラットフォームの実装に伴う多くの機能や能力が備わっていることを確認することが私たちにとって極めて重要でした。 また、実験と迅速なプロトタイピングについても言及しました。これにより、ユースケースが適切かどうかを判断し、適切でない場合は素早く失敗してから次のユースケースに移行するためのプラットフォームを持つことができます。 ユースケースに意味がある場合、AWSは私たちがそれらのユースケースを迅速に本番環境にスケールアップするためのプラットフォームを提供してくれます。
United における技術アーキテクチャについてお話しましょう。AI と ML は United にとって目新しいものではありません。私たちは約15年前から AI と ML を活用してきました。しかし、本当にエキサイティングだったのは、ここ15ヶ月間で構築した MLOps プラットフォームです。これは、クラウド上でモダン化した私たちのデータプラットフォーム、United Data Hub の上に構築されました。
このプラットフォームこそが、United における generative AI の加速と実装を可能にしたのです。AWS とのパートナーシップのもと、すべてのソリューションアーキテクトやパートナーの協力を得て、Amazon Bedrock を統合したプラットフォームを作成しました。Bedrock を MLOps プラットフォームの上に組み込むことで、先ほど話した機能が実現しました。つまり、API 呼び出しや複数の LLM モデルの選択などです。
そこから、Bedrock と MLOps プラットフォームを拡張して、Girish が話したようなナレッジベースやベクトルデータベースなどの機能を追加しました。これにより、文書の埋め込みや文書のチャンキングが可能になり、プロンプトやレスポンス、そして LLM モデルの会話の継続に必要なコンテキストとメモリを保持できるようになりました。さらに、API フレームワークを実装する際には、プロンプトとレスポンスをログに記録するサービスロギングなどの機能も拡張しました。これにより、United Data Hub の S3 に保存し、将来的にモデルの改善や微調整に活用できるようになりました。
また、このフレームワークにアクセラレータやアダプタを追加しました。これらはここでテンプレートとして表示されています。これらのテンプレートには、先ほど話した要約機能や chatbot テンプレートなどがあります。これらは私たちのユースケースやビジネスユーザーにとって非常に役立つものです。今後、さらに多くのユースケースが出てくるにつれ、これらのテンプレートが活用され続けるでしょう。これらのテンプレートを使用することで、実装を加速し、さらに重要なことに、ビジネスユーザーやアプリケーション開発パートナーが必要とするカスタム作業を削減できます。
最後に、私たちのような規模の企業にとって、generative AI の技術アーキテクチャに関する議論は、responsible AI の話題抜きには完結しません。これらの機能の多くは Bedrock に組み込まれていますが、私たちはレスポンスフィルターやコンテキストフィルターなど、さらに多くの機能を拡張しています。これにより、トーンや潜在的に有害なレスポンスなどをモニタリングし、ユースケースを進める中で人間を介在させながら、これらの問題を調整し排除していくことができます。
このスライドの重要なポイントは、AWSとBedrockが基盤となるインフラを提供し、それらを継続的に革新し、サポートしていくということです。私たちが重点を置くのは、ナレッジベースを作成するためのデータと、ビジネスに大きな価値を生み出し続けるためのプロンプトとレスポンスに焦点を当てることだと考えています。
United AirlinesのGenerative AI実装の学びとユースケース
ここ数ヶ月間の学びについて、先ほど説明した技術とフレームワークに基づいてお話しましょう。まず、私たちにとって役立ったのは、データとMLエンジニアリングチームを180度方向転換する必要がなかったことです。AWS MLOpsプラットフォームで構築した基盤から、さらに発展させることができました。これは、エンジニアたちや特に私のチームにとって、素晴らしい加速剤となり、これらのソリューションを迅速に市場に提供することができました。
次に、組織とコミュニケーションのフレームワークを構築することが非常に重要でした。私たちの規模と重要性を持つ企業をサポートするためには、Bedrockにおける生成AIの強みだけでなく、潜在的なリスクについてもメッセージを確実に伝える必要がありました。責任あるAIの要素をどのように管理し、関連するリスクをどのように管理するかについて取り組む必要がありました。これにより、適切なフレームワークを持って、これらのユースケースとプルーフオブコンセプトを成長させることができました。
学びをまとめると、この本には3つの章があります。第1章は、これらのユースケースとプルーフオブコンセプトを受け入れ、その準備状況を評価するためのフレームワークを提供するプログラム構造を作ることです。第2章は準備状況そのものについてで、フレームワークを確実に持つことです。私たちが使用したのは、一方の軸に価値を、もう一方の軸に複雑さを置いたマトリックスで、最初は高い価値と低い複雑さを持つものに焦点を当てました。これにより、高い価値を生み出すより複雑なユースケースに取り組むための経験を得ることができました。
では、どのようなユースケースがあったのでしょうか？私たちは本当に顧客に焦点を当て、従業員ベースについて話し合いました。
当社の成長を支えるために新たに入社する従業員の多くは、テクノロジーを愛する世代です。彼らはデジタルネイティブとして育ち、generative AIの使用を好みます。これは、顧客をより良くサポートし、コミュニケーションを最適化し、さらに重要なことに、顧客の感情や満足度を理解して実行可能なインサイトを導き出すために、私たちにとって完璧な適合だと感じています。
これらのユースケースを開発する際、私たちは顧客を中心に据えました。要約すると、4〜5つのカテゴリーのユースケースとモデルがあります。最初は要約と書き直しに関するものです。私たちには多くの複雑なポリシーやビジネスルールがあり、generative AIは特に、従業員が顧客に提示するための関連情報を要約し、抽出するのに役立ちます。これは大きな価値をもたらすと考えています。
2つ目は、よりインタラクティブで顧客と1対1のチャットボットのような会話型ユースケースです。ここでも、generative AIが情報を要約し、これらの会話を可能にするために情報を提供することに大きな価値を見出しています。これは、エージェントを通じてか、あるいは受賞歴のあるUnited mobileアプリを含むデジタルツールを通じて行われます。
3つ目はsentiment analysisです。先ほど申し上げたように、私たちには膨大な量のカスタマーフィードバックがあります。この知識ベースと私たちのプラットフォームを活用して、顧客満足度と体験を向上させるためのプロジェクトやイニシアチブを推進する、実用的な洞察を得ることができます。4つ目は、より新しい分野であるマルチモーダルLLMsに関するものです。これには、テキスト音声変換、音声テキスト変換、そして私が言及した他のすべてのユースケースの要約が含まれ、顧客と従業員の両方により没入感のある体験を提供し、カスタマーエクスペリエンスを向上させます。これは、この分野で前進する上でエキサイティングなフロンティアです。
さて、これらのユースケースを実現するためにAmazon Bedrockがどのように役立つと考えているかについて話しましょう。まず、私たちにとって繰り返しテーマとなるのは、責任あるAIとセキュリティです。Girishが言及したように、私たちのデータが基盤モデルのトレーニングに使用されないという信頼と確信があります。私たちの取引データは私たちのものであり、それが他の目的に使用されないという安心感を得るために重要です。
2つ目は、generative AIの民主化を可能にすることです。Bedrockが提供するモデルの選択肢により、企業全体にAIを広めることができると考えています。これはビジネス価値を提供する上で極めて重要です。3つ目はビジネス効率です。クラウドへの近代化を進める中で、多くのレガシープラットフォームやソフトウェアをgenerative AIを使って変革できると考えており、これは今後、価値を生み出す重要な分野になると思います。
最後に、おそらく最も重要なのは、Bedrockが提供するモデルの選択肢とカスタマイズ性です。まだ分からないことがたくさんあるので、実験し、遊び、これらのLLMsからの出力を継続的に改善するための選択肢を持つことが、中長期的にUnitedに価値を生み出す上で重要になるでしょう。
United AirlinesのGenerative AI将来展望とセッションのまとめ
さて、ここで私たちが始めた地点に戻り、これがどこに向かっているのか、私たちの今後の道筋、そしてこのイノベーションがどのように機能すると考えているかについて話しましょう。重要なテーマは、私たちがBedrockを使用し、AWSとパートナーシップを組んでいるのは、彼らがBedrockを継続的に革新し続けると信じているからです。これにより、私たちは自社のデータと、創造し考案するユースケースを使って価値を生み出すことに集中できるのです。
ここでは3つのカテゴリーについて説明したいと思います。まず当然ながら、責任あるAIとセキュリティに関する繰り返しのテーマがあります。私たちは顧客と従業員の安全を守るための適切なガードレールを設置しています。現在はプロンプトエンジニアリングなどに取り組んでいます。
Girishが検索拡張生成について話しました。これも私たちの重要な焦点となるでしょう。foundation modelsのデータに追加のコンテンツやナレッジベースをどのように加えて、確実に回答を提供し、特定の目的や価値のためにこれらのモデルを微調整できるようにするかということです。
2つ目はプラットフォームに関するものです。ここが本当に最適化が必要な部分です。このプレゼンテーションを通じて、コストについてはあまり触れていませんが、当社を含むどの企業にとっても非常に重要な考慮事項となるでしょう。今後を見据えると、コスト最適化が重要な要素となります。数十から数百のユースケースが市場に出てくるにつれて、このコストを管理する必要があり、それを念頭に置くことが重要だと考えています。ハードウェアの最適化、適切なユースケースに適切なチップを使用すること、そしてデータベースの最適化も、モデルのモニタリングやこれらのテストの実施と同様に、今後重要になってくるでしょう。また、想定した価値を生み出しているかを確認するための評価も重要です。
最後に、そして同様に重要なのは、モデル自体です。Amazon Bedrockが提供するカスタマーモデルの選択肢について話しましたが、今後さらに多くのモデルが登場するでしょう。私たちは特にこのマルチモーダルの機会に興味を持ち、わくわくしています。また、United向けにトレーニングされた特定のユースケースのためにモデルの微調整を行うことにも取り組んでいます。これにより、今後のコスト最適化にも役立ち、外部の大規模なトレーニング済みモデルを使用する必要がなくなるでしょう。
これらが近い将来に注目していく分野です。繰り返しになりますが、私たちの焦点はユースケースとデータにあります。一方で、AWSと提携してより革新的なAmazon Bedrockプラットフォームの強化と開発に取り組みます。これにより、データエンジニアとMLエンジニアは、ビジネス効率を創出し、さらに重要なことに、顧客が繰り返しUnited Airlinesを利用したくなるような顧客体験を生み出すために、ビジネス部門とのパートナーシップに集中できるようになります。これが私たちのストーリーです。ありがとうございました。それでは、Markにお返しします。
素晴らしい、ありがとうございましたSanjay。GirishとAmazon Bedrock について一日中話し合えるでしょう。でも、実際の顧客が生成AIをどのように提供し、Bedrockがどのように役立つかを説明してくれると、本当に印象深いものになります。ここで私たちの目標を達成できたと思います。Bedrockの各部分を説明するだけでなく、文脈の中で、これらの部分を結びつけ、多くの主要な機能、今週発表された多くの新機能を、一般的な生成AIタスクやユースケースの文脈の中で説明することを目指しました。そして、Unitedがそのプラットフォームでそのすべてを裏付けてくれたのを見るのは素晴らしかったです。
ここで簡単な行動の呼びかけをします。まだAmazon Bedrockを試していない方は、ぜひ試してみてください。AWS consoleに行けば簡単に使えます。自己学習トレーニングのためのワークショップも利用できます。Party Rockを訪れて、Bedrockを使って独自の生成AIアプリを作成することもできます。 すでにBedrockを使用している方は、どんな問題に遭遇しているか、何が好きで何が嫌いか、ロードマップで何を見たいかについて、ぜひ教えてください。ご存じのように、AWSではそういったフィードバックに基づいて開発を進めています。そのため、非常に楽しみにしています。さて、質問の時間がなくなってしまいましたので、ここで締めくくりたいと思います。後ほど外でお話しできれば幸いです。どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion